Application caching

[Guest Toni Van Remortel]

Hi all,

 

We have set up Server 2008 with Terminal Server for about 10 users.

All those users use the same application (a single exe from a network

share).

 

The drawback is that when we update the application (in-house development),

we need to ask all TS users to log out before they can use the new version.

Somehow, the exe is cached by the TS server as long as someone has it open,

and TS does not check if the exe on the network share is updated.

 

Is there a way to disable this behavior? When we update the application, a

simple close and reopen should open the new version, not the old cached

version.

 

Thanks a lot.

--

Regards,

Toni Van Remortel

[Guest Jeff Pitsch]

Re: Application caching

 

This is standard OS behaviour. I'm not sure what your expecting. Windows

has to make sure that the application is "locked" in case it needs to read

from it again. If the application is changed in the middle of user using it

the implications include crashing the user's application and potentially

session and potentially worse.

 

Jeff Pitsch

Microsoft MVP - Terminal Services

 

 

"Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

news:RGGdk.121644$jB5.81602@newsfe05.ams2...

> Hi all,

>

> We have set up Server 2008 with Terminal Server for about 10 users.

> All those users use the same application (a single exe from a network

> share).

>

> The drawback is that when we update the application (in-house

> development),

> we need to ask all TS users to log out before they can use the new

> version.

> Somehow, the exe is cached by the TS server as long as someone has it

> open,

> and TS does not check if the exe on the network share is updated.

>

> Is there a way to disable this behavior? When we update the application, a

> simple close and reopen should open the new version, not the old cached

> version.

>

> Thanks a lot.

> --

> Regards,

> Toni Van Remortel

[Guest jolteroli]

Re: Application caching

 

---[ RunApp.bat ]-----------------------------

copy /B /Y \\server\share\app.exe %TEMP%\app.exe

start %TEMP%\app.exe

----------------------------------------------

 

Make a short cut to this batch file, set a nice icon

and start it minimized. The "cmd.exe" process will die

and leave the app running from the temp directory.

 

If users should start multiple instances, the first

copy will fail, but the app will start anyway. For

an update, the user must close all instances and start

the short cut again and the copy will succeed.

 

See also for the "use per session temp dir" and

"delete temp dir on logoff" group policy. Not sure

about the exact name, since we have the german version.

 

Hope this will do the trick.

 

-jolt

[Guest Toni Van Remortel]

Re: Application caching

 

I would expect such a behavior for every user session, but not for all users

logged in at the same time.

 

In correct multi-user environments, every user has it's copy of the program

cached in memory, but it is unlikely that when the user closes the

application and start it again, that the OS wouldn't read it again from

disk (specially when it has changed).

 

So now we are stuck for program updates. Terminal Server users have to

collectively log out of their sessions before they can use the new software

version.

 

I don't think that is 'standard OS behavior'. That is a serious bug.

 

--

Regards,

Toni Van Remortel

 

 

Jeff Pitsch wrote:

> This is standard OS behaviour. I'm not sure what your expecting. Windows

> has to make sure that the application is "locked" in case it needs to read

> from it again. If the application is changed in the middle of user using

> it the implications include crashing the user's application and

> potentially session and potentially worse.

>

> Jeff Pitsch

> Microsoft MVP - Terminal Services

>

>

> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

> news:RGGdk.121644$jB5.81602@newsfe05.ams2...

>> Hi all,

>>

>> We have set up Server 2008 with Terminal Server for about 10 users.

>> All those users use the same application (a single exe from a network

>> share).

>>

>> The drawback is that when we update the application (in-house

>> development),

>> we need to ask all TS users to log out before they can use the new

>> version.

>> Somehow, the exe is cached by the TS server as long as someone has it

>> open,

>> and TS does not check if the exe on the network share is updated.

>>

>> Is there a way to disable this behavior? When we update the application,

>> a simple close and reopen should open the new version, not the old cached

>> version.

>>

>> Thanks a lot.

>> --

>> Regards,

>> Toni Van Remortel

[Guest jolteroli]

Re: Application caching

 

Toni,

 

this behaviour is quite normal, because the windows memory management only

use parts of the executable in memory. If code relocations are done after

loading the executable, the relocation table is evicted form physical

memory. Now, if parts of the executable gets needed again, Windows just

swaps in the missing part from the file.

 

Could you imaging what happens if the file has changed? To avoid such a

messup, Windows simply locks the whole file, because the executable it self

is used as "file backed virtual memory".

 

-jolt

[Guest Jeff Pitsch]

Re: Application caching

 

No this is standard and if you really think of the consequences of changing

an executable while being used you'll realize this is for the better.

Remember, just because something is in memory doesn't mean it's not be ing

used off the disk or locked. You also have to realize that making changes

to a program in the middle of the day is NOT normal by any stretch. You

always make changes on a scheduled basis. Also due to shared memory of

windows, just because an executable has changed doesn't mean it gets

reloaded. The exeuctable is already in memory, why should it reload the

entire thing again?

 

Can you imagine upgrading Office while users are using the software? What a

disaster that would be.

 

Jeff Pitsch

Microsoft MVP - Terminal Services

 

 

"Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

news:ghKdk.157661$8H5.84843@newsfe10.ams2...

>I would expect such a behavior for every user session, but not for all

>users

> logged in at the same time.

>

> In correct multi-user environments, every user has it's copy of the

> program

> cached in memory, but it is unlikely that when the user closes the

> application and start it again, that the OS wouldn't read it again from

> disk (specially when it has changed).

>

> So now we are stuck for program updates. Terminal Server users have to

> collectively log out of their sessions before they can use the new

> software

> version.

>

> I don't think that is 'standard OS behavior'. That is a serious bug.

>

> --

> Regards,

> Toni Van Remortel

>

>

> Jeff Pitsch wrote:

>

>> This is standard OS behaviour. I'm not sure what your expecting.

>> Windows

>> has to make sure that the application is "locked" in case it needs to

>> read

>> from it again. If the application is changed in the middle of user using

>> it the implications include crashing the user's application and

>> potentially session and potentially worse.

>>

>> Jeff Pitsch

>> Microsoft MVP - Terminal Services

>>

>>

>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

>> news:RGGdk.121644$jB5.81602@newsfe05.ams2...

>>> Hi all,

>>>

>>> We have set up Server 2008 with Terminal Server for about 10 users.

>>> All those users use the same application (a single exe from a network

>>> share).

>>>

>>> The drawback is that when we update the application (in-house

>>> development),

>>> we need to ask all TS users to log out before they can use the new

>>> version.

>>> Somehow, the exe is cached by the TS server as long as someone has it

>>> open,

>>> and TS does not check if the exe on the network share is updated.

>>>

>>> Is there a way to disable this behavior? When we update the application,

>>> a simple close and reopen should open the new version, not the old

>>> cached

>>> version.

>>>

>>> Thanks a lot.

>>> --

>>> Regards,

>>> Toni Van Remortel

[Guest Toni Van Remortel]

Re: Application caching

 

1) Changing software during daily work is common here (multiple reasons for

that).

 

2) Workstation users have no problems closing the app and starting it again

to use the new version.

 

3) Still, using shared memory from other user sessions is ... very secure.

 

4) I didn't mention Office as software , I did mention an application we

develop ourselves. And this application has descent library usage. The only

thing a user need to reload, is the main exe, which should be possible with

a single close->reopen.

 

5) If the exe is still in memory, it should read it from disk again if it

has changed on disk! What would be the point of the modification date then?

 

I have my serious doubts about TS, security wise and multi-user wise.

 

Anyway, seems we have to live with this bug.

 

Regards,

Toni

 

 

Jeff Pitsch wrote:

> No this is standard and if you really think of the consequences of

> changing an executable while being used you'll realize this is for the

> better. Remember, just because something is in memory doesn't mean it's

> not be ing

> used off the disk or locked. You also have to realize that making changes

> to a program in the middle of the day is NOT normal by any stretch. You

> always make changes on a scheduled basis. Also due to shared memory of

> windows, just because an executable has changed doesn't mean it gets

> reloaded. The exeuctable is already in memory, why should it reload the

> entire thing again?

>

> Can you imagine upgrading Office while users are using the software? What

> a disaster that would be.

>

> Jeff Pitsch

> Microsoft MVP - Terminal Services

>

>

> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

> news:ghKdk.157661$8H5.84843@newsfe10.ams2...

>>I would expect such a behavior for every user session, but not for all

>>users

>> logged in at the same time.

>>

>> In correct multi-user environments, every user has it's copy of the

>> program

>> cached in memory, but it is unlikely that when the user closes the

>> application and start it again, that the OS wouldn't read it again from

>> disk (specially when it has changed).

>>

>> So now we are stuck for program updates. Terminal Server users have to

>> collectively log out of their sessions before they can use the new

>> software

>> version.

>>

>> I don't think that is 'standard OS behavior'. That is a serious bug.

>>

>> --

>> Regards,

>> Toni Van Remortel

>>

>>

>> Jeff Pitsch wrote:

>>

>>> This is standard OS behaviour. I'm not sure what your expecting.

>>> Windows

>>> has to make sure that the application is "locked" in case it needs to

>>> read

>>> from it again. If the application is changed in the middle of user

>>> using it the implications include crashing the user's application and

>>> potentially session and potentially worse.

>>>

>>> Jeff Pitsch

>>> Microsoft MVP - Terminal Services

>>>

>>>

>>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

>>> news:RGGdk.121644$jB5.81602@newsfe05.ams2...

>>>> Hi all,

>>>>

>>>> We have set up Server 2008 with Terminal Server for about 10 users.

>>>> All those users use the same application (a single exe from a network

>>>> share).

>>>>

>>>> The drawback is that when we update the application (in-house

>>>> development),

>>>> we need to ask all TS users to log out before they can use the new

>>>> version.

>>>> Somehow, the exe is cached by the TS server as long as someone has it

>>>> open,

>>>> and TS does not check if the exe on the network share is updated.

>>>>

>>>> Is there a way to disable this behavior? When we update the

>>>> application, a simple close and reopen should open the new version, not

>>>> the old cached

>>>> version.

>>>>

>>>> Thanks a lot.

>>>> --

>>>> Regards,

>>>> Toni Van Remortel

 

--

Regards,

Toni Van Remortel

[Guest Jeff Pitsch]

Re: Application caching

 

I would highly recommend getting to know TS first before saying anything

about it's security. It is very secure and it's your unfamiliarity with how

windows uses memory that is causing the issue here. This has nothing to do

with TS but with Windows in general and almost all OS's. They all work the

same. You are simply used to working in a singloe user environment which is

why it's difficult to understand why this is happening.

 

Again, this is not a bug but the way windows works. Your even confirming by

saying that users log out and log back in to get the new exe to load into

memory. Why would TS function any differently? Your app isn't dynamically

loaded when it changes, again, why would you expect TS to function any

differently.

 

I will say this again, this is not TS but the way windows works and your

unfamiliarity with terminal services and muti-user. If security was an

issue like you seem to think it is, well, I know I personally wouldn't have

been able to load/configure/architect solutions in some highly secure areas

where something like this wouldn't be tolerated.

 

Jeff Pitsch

Microsoft MVP - Terminal Services

 

 

"Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

news:KNFek.151686$Kb.28741@newsfe29.ams2...

> 1) Changing software during daily work is common here (multiple reasons

> for

> that).

>

> 2) Workstation users have no problems closing the app and starting it

> again

> to use the new version.

>

> 3) Still, using shared memory from other user sessions is ... very secure.

>

> 4) I didn't mention Office as software , I did mention an application we

> develop ourselves. And this application has descent library usage. The

> only

> thing a user need to reload, is the main exe, which should be possible

> with

> a single close->reopen.

>

> 5) If the exe is still in memory, it should read it from disk again if it

> has changed on disk! What would be the point of the modification date

> then?

>

> I have my serious doubts about TS, security wise and multi-user wise.

>

> Anyway, seems we have to live with this bug.

>

> Regards,

> Toni

>

>

> Jeff Pitsch wrote:

>

>> No this is standard and if you really think of the consequences of

>> changing an executable while being used you'll realize this is for the

>> better. Remember, just because something is in memory doesn't mean it's

>> not be ing

>> used off the disk or locked. You also have to realize that making

>> changes

>> to a program in the middle of the day is NOT normal by any stretch. You

>> always make changes on a scheduled basis. Also due to shared memory of

>> windows, just because an executable has changed doesn't mean it gets

>> reloaded. The exeuctable is already in memory, why should it reload the

>> entire thing again?

>>

>> Can you imagine upgrading Office while users are using the software?

>> What

>> a disaster that would be.

>>

>> Jeff Pitsch

>> Microsoft MVP - Terminal Services

>>

>>

>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

>> news:ghKdk.157661$8H5.84843@newsfe10.ams2...

>>>I would expect such a behavior for every user session, but not for all

>>>users

>>> logged in at the same time.

>>>

>>> In correct multi-user environments, every user has it's copy of the

>>> program

>>> cached in memory, but it is unlikely that when the user closes the

>>> application and start it again, that the OS wouldn't read it again from

>>> disk (specially when it has changed).

>>>

>>> So now we are stuck for program updates. Terminal Server users have to

>>> collectively log out of their sessions before they can use the new

>>> software

>>> version.

>>>

>>> I don't think that is 'standard OS behavior'. That is a serious bug.

>>>

>>> --

>>> Regards,

>>> Toni Van Remortel

>>>

>>>

>>> Jeff Pitsch wrote:

>>>

>>>> This is standard OS behaviour. I'm not sure what your expecting.

>>>> Windows

>>>> has to make sure that the application is "locked" in case it needs to

>>>> read

>>>> from it again. If the application is changed in the middle of user

>>>> using it the implications include crashing the user's application and

>>>> potentially session and potentially worse.

>>>>

>>>> Jeff Pitsch

>>>> Microsoft MVP - Terminal Services

>>>>

>>>>

>>>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

>>>> news:RGGdk.121644$jB5.81602@newsfe05.ams2...

>>>>> Hi all,

>>>>>

>>>>> We have set up Server 2008 with Terminal Server for about 10 users.

>>>>> All those users use the same application (a single exe from a network

>>>>> share).

>>>>>

>>>>> The drawback is that when we update the application (in-house

>>>>> development),

>>>>> we need to ask all TS users to log out before they can use the new

>>>>> version.

>>>>> Somehow, the exe is cached by the TS server as long as someone has it

>>>>> open,

>>>>> and TS does not check if the exe on the network share is updated.

>>>>>

>>>>> Is there a way to disable this behavior? When we update the

>>>>> application, a simple close and reopen should open the new version,

>>>>> not

>>>>> the old cached

>>>>> version.

>>>>>

>>>>> Thanks a lot.

>>>>> --

>>>>> Regards,

>>>>> Toni Van Remortel

>

> --

> Regards,

> Toni Van Remortel

[Guest Toni Van Remortel]

Re: Application caching

 

I guess you aren't understanding the situation, so I'll make it clear again:

 

- User1 to User8 are logged in in TS and all have app.exe (v1) running.

- app.exe (v1) is changed on the NAS to a new version (v2).

- User1 closes app.exe (v1) and opens app.exe (v2) from the NAS, but sees

app.exe (v1) appearing on his screen.

- User1 logs out from TS, logs in again and tries to open app.exe (v2) from

the NAS. Again, he sees app.exe (v1) appearing.

- User1 to User8 all close app.exe (v1).

- User1 tries to open app.exe (v2) from the NAS, but still gets app.exe

(v2).

- User1 logs out again from TS, logs in again to TS and tries to open

app.exe (v2) from the NAS. Again, he sees app.exe (v1) appearing.

- Bored like hell, we ask User1 to User8 to log out from TS.

- User1 logs in again to TS and tries to open app.exe (v2) from the NAS.

Finally he sees app.exe (v2).

- User2 to User8 log back in into TS, open app.exe (v2) from the NAS and can

work again with app.exe (v2).

 

Don't tell me that is 'standard OS behavior'.

 

The NAS is not caching anything, as app.exe (v2) appears on the desktop

workstations after a close of app.exe (v1) and opening app.exe (v2) from

the NAS.

 

PS: I'm used to multi-user environments. In LTSP for example, I haven't seen

any behavior like this before.

 

Regards,

Toni

 

Jeff Pitsch wrote:

> I would highly recommend getting to know TS first before saying anything

> about it's security. It is very secure and it's your unfamiliarity with

> how

> windows uses memory that is causing the issue here. This has nothing to

> do

> with TS but with Windows in general and almost all OS's. They all work

> the

> same. You are simply used to working in a singloe user environment which

> is why it's difficult to understand why this is happening.

>

> Again, this is not a bug but the way windows works. Your even confirming

> by saying that users log out and log back in to get the new exe to load

> into

> memory. Why would TS function any differently? Your app isn't

> dynamically loaded when it changes, again, why would you expect TS to

> function any differently.

>

> I will say this again, this is not TS but the way windows works and your

> unfamiliarity with terminal services and muti-user. If security was an

> issue like you seem to think it is, well, I know I personally wouldn't

> have been able to load/configure/architect solutions in some highly secure

> areas where something like this wouldn't be tolerated.

>

> Jeff Pitsch

> Microsoft MVP - Terminal Services

>

>

> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

> news:KNFek.151686$Kb.28741@newsfe29.ams2...

>> 1) Changing software during daily work is common here (multiple reasons

>> for

>> that).

>>

>> 2) Workstation users have no problems closing the app and starting it

>> again

>> to use the new version.

>>

>> 3) Still, using shared memory from other user sessions is ... very

>> secure.

>>

>> 4) I didn't mention Office as software , I did mention an application we

>> develop ourselves. And this application has descent library usage. The

>> only

>> thing a user need to reload, is the main exe, which should be possible

>> with

>> a single close->reopen.

>>

>> 5) If the exe is still in memory, it should read it from disk again if it

>> has changed on disk! What would be the point of the modification date

>> then?

>>

>> I have my serious doubts about TS, security wise and multi-user wise.

>>

>> Anyway, seems we have to live with this bug.

>>

>> Regards,

>> Toni

>>

>>

>> Jeff Pitsch wrote:

>>

>>> No this is standard and if you really think of the consequences of

>>> changing an executable while being used you'll realize this is for the

>>> better. Remember, just because something is in memory doesn't mean it's

>>> not be ing

>>> used off the disk or locked. You also have to realize that making

>>> changes

>>> to a program in the middle of the day is NOT normal by any stretch. You

>>> always make changes on a scheduled basis. Also due to shared memory of

>>> windows, just because an executable has changed doesn't mean it gets

>>> reloaded. The exeuctable is already in memory, why should it reload the

>>> entire thing again?

>>>

>>> Can you imagine upgrading Office while users are using the software?

>>> What

>>> a disaster that would be.

>>>

>>> Jeff Pitsch

>>> Microsoft MVP - Terminal Services

>>>

>>>

>>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

>>> news:ghKdk.157661$8H5.84843@newsfe10.ams2...

>>>>I would expect such a behavior for every user session, but not for all

>>>>users

>>>> logged in at the same time.

>>>>

>>>> In correct multi-user environments, every user has it's copy of the

>>>> program

>>>> cached in memory, but it is unlikely that when the user closes the

>>>> application and start it again, that the OS wouldn't read it again from

>>>> disk (specially when it has changed).

>>>>

>>>> So now we are stuck for program updates. Terminal Server users have to

>>>> collectively log out of their sessions before they can use the new

>>>> software

>>>> version.

>>>>

>>>> I don't think that is 'standard OS behavior'. That is a serious bug.

>>>>

>>>> --

>>>> Regards,

>>>> Toni Van Remortel

>>>>

>>>>

>>>> Jeff Pitsch wrote:

>>>>

>>>>> This is standard OS behaviour. I'm not sure what your expecting.

>>>>> Windows

>>>>> has to make sure that the application is "locked" in case it needs to

>>>>> read

>>>>> from it again. If the application is changed in the middle of user

>>>>> using it the implications include crashing the user's application and

>>>>> potentially session and potentially worse.

>>>>>

>>>>> Jeff Pitsch

>>>>> Microsoft MVP - Terminal Services

>>>>>

>>>>>

>>>>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in

>>>>> message news:RGGdk.121644$jB5.81602@newsfe05.ams2...

>>>>>> Hi all,

>>>>>>

>>>>>> We have set up Server 2008 with Terminal Server for about 10 users.

>>>>>> All those users use the same application (a single exe from a network

>>>>>> share).

>>>>>>

>>>>>> The drawback is that when we update the application (in-house

>>>>>> development),

>>>>>> we need to ask all TS users to log out before they can use the new

>>>>>> version.

>>>>>> Somehow, the exe is cached by the TS server as long as someone has it

>>>>>> open,

>>>>>> and TS does not check if the exe on the network share is updated.

>>>>>>

>>>>>> Is there a way to disable this behavior? When we update the

>>>>>> application, a simple close and reopen should open the new version,

>>>>>> not

>>>>>> the old cached

>>>>>> version.

>>>>>>

>>>>>> Thanks a lot.

>>>>>> --

>>>>>> Regards,

>>>>>> Toni Van Remortel

>>

>> --

>> Regards,

>> Toni Van Remortel

 

--

Regards,

Toni Van Remortel

[Guest Jeff Pitsch]

Re: Application caching

 

I completely understand what you are saying but you are not understanding

that this is normal Windows behaviour. You've argued the point and made my

point to your repeated references to how a single user Windows system works.

You are not used to working with Windows when dealing with multiple users on

the same system. To conserve memory, windows shares a readonly file in

memory. That is why you are seeing this. This is NOT caching. Windows

doesn't cache applications.

 

This is obviously not getting anywhere. What you are seeing is normal based

on Windows OS. I would highly suggest calling Microsoft as the forum is not

giving you the answer you want. Calling htem directly and talking with them

and ask them to change the OS behaviour will at least let them know what you

want from the OS.

 

Let me ask you this. On Windows XP or whatever client OS you are using, if

you start the app, replace the file, then try to start it again while the

app is running, what happens? does it start the new version?

 

Jeff Pitsch

Microsoft MVP - Terminal Services

 

"Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

news:LC_ek.5530$5A2.4792@newsfe29.ams2...

>I guess you aren't understanding the situation, so I'll make it clear

>again:

>

> - User1 to User8 are logged in in TS and all have app.exe (v1) running.

> - app.exe (v1) is changed on the NAS to a new version (v2).

> - User1 closes app.exe (v1) and opens app.exe (v2) from the NAS, but sees

> app.exe (v1) appearing on his screen.

> - User1 logs out from TS, logs in again and tries to open app.exe (v2)

> from

> the NAS. Again, he sees app.exe (v1) appearing.

> - User1 to User8 all close app.exe (v1).

> - User1 tries to open app.exe (v2) from the NAS, but still gets app.exe

> (v2).

> - User1 logs out again from TS, logs in again to TS and tries to open

> app.exe (v2) from the NAS. Again, he sees app.exe (v1) appearing.

> - Bored like hell, we ask User1 to User8 to log out from TS.

> - User1 logs in again to TS and tries to open app.exe (v2) from the NAS.

> Finally he sees app.exe (v2).

> - User2 to User8 log back in into TS, open app.exe (v2) from the NAS and

> can

> work again with app.exe (v2).

>

> Don't tell me that is 'standard OS behavior'.

>

> The NAS is not caching anything, as app.exe (v2) appears on the desktop

> workstations after a close of app.exe (v1) and opening app.exe (v2) from

> the NAS.

>

> PS: I'm used to multi-user environments. In LTSP for example, I haven't

> seen

> any behavior like this before.

>

> Regards,

> Toni

>

> Jeff Pitsch wrote:

>

>> I would highly recommend getting to know TS first before saying anything

>> about it's security. It is very secure and it's your unfamiliarity with

>> how

>> windows uses memory that is causing the issue here. This has nothing to

>> do

>> with TS but with Windows in general and almost all OS's. They all work

>> the

>> same. You are simply used to working in a singloe user environment which

>> is why it's difficult to understand why this is happening.

>>

>> Again, this is not a bug but the way windows works. Your even confirming

>> by saying that users log out and log back in to get the new exe to load

>> into

>> memory. Why would TS function any differently? Your app isn't

>> dynamically loaded when it changes, again, why would you expect TS to

>> function any differently.

>>

>> I will say this again, this is not TS but the way windows works and your

>> unfamiliarity with terminal services and muti-user. If security was an

>> issue like you seem to think it is, well, I know I personally wouldn't

>> have been able to load/configure/architect solutions in some highly

>> secure

>> areas where something like this wouldn't be tolerated.

>>

>> Jeff Pitsch

>> Microsoft MVP - Terminal Services

>>

>>

>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

>> news:KNFek.151686$Kb.28741@newsfe29.ams2...

>>> 1) Changing software during daily work is common here (multiple reasons

>>> for

>>> that).

>>>

>>> 2) Workstation users have no problems closing the app and starting it

>>> again

>>> to use the new version.

>>>

>>> 3) Still, using shared memory from other user sessions is ... very

>>> secure.

>>>

>>> 4) I didn't mention Office as software , I did mention an application we

>>> develop ourselves. And this application has descent library usage. The

>>> only

>>> thing a user need to reload, is the main exe, which should be possible

>>> with

>>> a single close->reopen.

>>>

>>> 5) If the exe is still in memory, it should read it from disk again if

>>> it

>>> has changed on disk! What would be the point of the modification date

>>> then?

>>>

>>> I have my serious doubts about TS, security wise and multi-user wise.

>>>

>>> Anyway, seems we have to live with this bug.

>>>

>>> Regards,

>>> Toni

>>>

>>>

>>> Jeff Pitsch wrote:

>>>

>>>> No this is standard and if you really think of the consequences of

>>>> changing an executable while being used you'll realize this is for the

>>>> better. Remember, just because something is in memory doesn't mean it's

>>>> not be ing

>>>> used off the disk or locked. You also have to realize that making

>>>> changes

>>>> to a program in the middle of the day is NOT normal by any stretch.

>>>> You

>>>> always make changes on a scheduled basis. Also due to shared memory of

>>>> windows, just because an executable has changed doesn't mean it gets

>>>> reloaded. The exeuctable is already in memory, why should it reload

>>>> the

>>>> entire thing again?

>>>>

>>>> Can you imagine upgrading Office while users are using the software?

>>>> What

>>>> a disaster that would be.

>>>>

>>>> Jeff Pitsch

>>>> Microsoft MVP - Terminal Services

>>>>

>>>>

>>>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message

>>>> news:ghKdk.157661$8H5.84843@newsfe10.ams2...

>>>>>I would expect such a behavior for every user session, but not for all

>>>>>users

>>>>> logged in at the same time.

>>>>>

>>>>> In correct multi-user environments, every user has it's copy of the

>>>>> program

>>>>> cached in memory, but it is unlikely that when the user closes the

>>>>> application and start it again, that the OS wouldn't read it again

>>>>> from

>>>>> disk (specially when it has changed).

>>>>>

>>>>> So now we are stuck for program updates. Terminal Server users have to

>>>>> collectively log out of their sessions before they can use the new

>>>>> software

>>>>> version.

>>>>>

>>>>> I don't think that is 'standard OS behavior'. That is a serious bug.

>>>>>

>>>>> --

>>>>> Regards,

>>>>> Toni Van Remortel

>>>>>

>>>>>

>>>>> Jeff Pitsch wrote:

>>>>>

>>>>>> This is standard OS behaviour. I'm not sure what your expecting.

>>>>>> Windows

>>>>>> has to make sure that the application is "locked" in case it needs to

>>>>>> read

>>>>>> from it again. If the application is changed in the middle of user

>>>>>> using it the implications include crashing the user's application and

>>>>>> potentially session and potentially worse.

>>>>>>

>>>>>> Jeff Pitsch

>>>>>> Microsoft MVP - Terminal Services

>>>>>>

>>>>>>

>>>>>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in

>>>>>> message news:RGGdk.121644$jB5.81602@newsfe05.ams2...

>>>>>>> Hi all,

>>>>>>>

>>>>>>> We have set up Server 2008 with Terminal Server for about 10 users.

>>>>>>> All those users use the same application (a single exe from a

>>>>>>> network

>>>>>>> share).

>>>>>>>

>>>>>>> The drawback is that when we update the application (in-house

>>>>>>> development),

>>>>>>> we need to ask all TS users to log out before they can use the new

>>>>>>> version.

>>>>>>> Somehow, the exe is cached by the TS server as long as someone has

>>>>>>> it

>>>>>>> open,

>>>>>>> and TS does not check if the exe on the network share is updated.

>>>>>>>

>>>>>>> Is there a way to disable this behavior? When we update the

>>>>>>> application, a simple close and reopen should open the new version,

>>>>>>> not

>>>>>>> the old cached

>>>>>>> version.

>>>>>>>

>>>>>>> Thanks a lot.

>>>>>>> --

>>>>>>> Regards,

>>>>>>> Toni Van Remortel

>>>

>>> --

>>> Regards,

>>> Toni Van Remortel

>

> --

> Regards,

> Toni Van Remortel

[Guest Toni Van Remortel]

Re: Application caching

 

Jeff Pitsch wrote:

> Let me ask you this. On Windows XP or whatever client OS you are using,

> if you start the app, replace the file, then try to start it again while

> the app is running, what happens? does it start the new version?

 

Yes it does. And then tells me it is already running.

 

So TS is not the system we need. Good to know, I'll head for alternatives.

--

Regards,

Toni Van Remortel

[Guest TP]

Re: Application caching

 

Hi Toni,

 

When a user runs an exe from a network share a read

lock should be held until the program has been closed. This

will prevent you from deleting the exe, replacing it with a

new one, etc. Now, it is clear in your case that this is not

happening for some reason.

 

What operating system is running on the device that is

providing the network share (the one where the exe is located)?

 

Thanks.

 

-TP

 

Toni Van Remortel wrote:

> Hi all,

>

> We have set up Server 2008 with Terminal Server for about 10 users.

> All those users use the same application (a single exe from a network

> share).

>

> The drawback is that when we update the application (in-house

> development), we need to ask all TS users to log out before they can

> use the new version. Somehow, the exe is cached by the TS server as

> long as someone has it open, and TS does not check if the exe on the

> network share is updated.

>

> Is there a way to disable this behavior? When we update the

> application, a simple close and reopen should open the new version,

> not the old cached version.

>

> Thanks a lot.

[Guest Toni Van Remortel]

Re: Application caching

 

TP wrote:

> Hi Toni,

>

> When a user runs an exe from a network share a read

> lock should be held until the program has been closed. This

> will prevent you from deleting the exe, replacing it with a

> new one, etc. Now, it is clear in your case that this is not

> happening for some reason.

>

> What operating system is running on the device that is

> providing the network share (the one where the exe is located)?

 

We use Samba Version 3.0.28a.

The file state on the app on the server is:

DENY_WRITE 0xa1 RDONLY

 

The way to upgrade our app is by overwriting the version on the server (not

through Samba, but through SSH on Linux) and ask the users to close and

open the app again. Works like a charm.

 

PS: We have no problems on workstations. And as far as I'm following the

story right now, a user that closes the app should equal closing the app by

all TS users (which still doesn't clear the 'shared memory'). Still not the

same story.

--

Regards,

Toni Van Remortel

[Guest jolteroli]

Re: Application caching

 

Toni,

 

could you try to disable opportunistic locking on that share?

 

oplocks = False

level2oplocks = False

 

Since executable are never written back, this should have no performance

impact as stated in documentation.

 

BTW: If it seems to you sharing shareable memory between processes is a

security flaw, have a look at the copy-on-write "trick" today operating

systems use to protect such memory regions. And yes, Linux do it the same

way, because it is a feature of the 386+ mmu.

 

-jolt

[Guest TP]

Re: Application caching

 

Hi Toni,

 

You are using an unsupported technique. Normal and expected

behavior is for an exe file to be locked when the application is in

use. This is true for exes loaded from the local drive or a

network share.

 

Try a quick experiment yourself: copy calc.exe from c:\windows\system32

to your desktop, run it, and then try and delete calc.exe from your

desktop--you can't. Same thing if you copy it to a network share

(a SMB share provided by a windows OS). This is true whether

on a workstation or server OS.

 

This is the reason when you apply updates to many popular

programs they ask you to shutdown the application first. For

example Adobe Reader will prompt you and then automatically

close the running instance of Reader so that it can update to a

new version.

 

You have found a method to circumvent correct locking behavior.

Think about it for a moment: what good is having a lock on a file

if someone can come along and replace the entire file at will? I

don't know why Samba/Linux allows you to do this.

 

I am very familar with the problem. You have an in-house application

that you need/want to update during the day when people are

working. The trouble is you can't do it until all users have exited

the application.

 

The way I have tackled it in the past is to have an app shutdown/restart

capability built-in to my code. I have an admin console of the program

which signals the running instances of the application to close and run a

different exe. This different exe waits for the main exe to be replaced

and then automatically restarts the new version of the main app.

 

In another case I created a program that would terminate all running

instances on the network of a particular application so that maintenance

could be performed. I did not have access to the source code. This

was *not* dangerous because I analyzed the application, tested, and

determined that the termination would not cause data loss.

 

Thanks.

 

-TP

 

Toni Van Remortel wrote:

> We use Samba Version 3.0.28a.

> The file state on the app on the server is:

> DENY_WRITE 0xa1 RDONLY

>

> The way to upgrade our app is by overwriting the version on the

> server (not through Samba, but through SSH on Linux) and ask the

> users to close and open the app again. Works like a charm.

>

> PS: We have no problems on workstations. And as far as I'm following

> the story right now, a user that closes the app should equal closing

> the app by all TS users (which still doesn't clear the 'shared

> memory'). Still not the same story.

[Guest Jeff Pitsch]

Re: Application caching

 

Thanks TP.

 

Jeff Pitsch

Microsoft MVP - Terminal Services

 

 

"TP" <tperson.knowspamn@mailandnews.com> wrote in message

news:%23kICUY%235IHA.1204@TK2MSFTNGP04.phx.gbl...

> Hi Toni,

>

> You are using an unsupported technique. Normal and expected behavior is

> for an exe file to be locked when the application is in use. This is true

> for exes loaded from the local drive or a network share.

>

> Try a quick experiment yourself: copy calc.exe from c:\windows\system32 to

> your desktop, run it, and then try and delete calc.exe from your

> desktop--you can't. Same thing if you copy it to a network share (a SMB

> share provided by a windows OS). This is true whether on a workstation or

> server OS.

>

> This is the reason when you apply updates to many popular programs they

> ask you to shutdown the application first. For example Adobe Reader will

> prompt you and then automatically close the running instance of Reader so

> that it can update to a new version.

>

> You have found a method to circumvent correct locking behavior. Think

> about it for a moment: what good is having a lock on a file if someone can

> come along and replace the entire file at will? I don't know why

> Samba/Linux allows you to do this.

>

> I am very familar with the problem. You have an in-house application that

> you need/want to update during the day when people are working. The

> trouble is you can't do it until all users have exited the application.

>

> The way I have tackled it in the past is to have an app shutdown/restart

> capability built-in to my code. I have an admin console of the program

> which signals the running instances of the application to close and run a

> different exe. This different exe waits for the main exe to be replaced

> and then automatically restarts the new version of the main app.

>

> In another case I created a program that would terminate all running

> instances on the network of a particular application so that maintenance

> could be performed. I did not have access to the source code. This was

> *not* dangerous because I analyzed the application, tested, and determined

> that the termination would not cause data loss.

>

> Thanks.

>

> -TP

>

> Toni Van Remortel wrote:

>> We use Samba Version 3.0.28a.

>> The file state on the app on the server is:

>> DENY_WRITE 0xa1 RDONLY

>>

>> The way to upgrade our app is by overwriting the version on the

>> server (not through Samba, but through SSH on Linux) and ask the

>> users to close and open the app again. Works like a charm.

>>

>> PS: We have no problems on workstations. And as far as I'm following

>> the story right now, a user that closes the app should equal closing

>> the app by all TS users (which still doesn't clear the 'shared

>> memory'). Still not the same story.

[Guest TP]

Re: Application caching

 

You are welcome Jeff.

 

-TP

 

Jeff Pitsch wrote:

> Thanks TP.

>

> Jeff Pitsch

> Microsoft MVP - Terminal Services

[Guest Toni Van Remortel]

Re: Application caching

 

Hi TP,

 

Thanks for your explanation about the locking mechanism. I know this method,

and I'm aware of it's function.

We do go around the locking of the exe on Linux to make our lives easier

(just send a mail to the users telling them to restart the app when they

want to, to get the new version). It works perfectly in a workstation

environment.

 

But that still doesn't explain why the old app is openend on the Terminal

Server if ALL TS users have closed it. It only disappears when ALL TS users

log out of TS (while workstation users don't need to log out to get the new

app, tehy only need to close it and reopen it).

That is my concern. If nobody has the app open, why is the old app still

coming back?

 

In my view, there is no difference between a single workstation and a

Terminal Server. If every TS users closes the app, it should resemble the

same situation as if the workstation user closes the app. I have no clue

why Terminal Server would keep the old app in memory, while a workstation

doesn't.

 

Regards,

Toni

 

TP wrote:

> Hi Toni,

>

> You are using an unsupported technique. Normal and expected

> behavior is for an exe file to be locked when the application is in

> use. This is true for exes loaded from the local drive or a

> network share.

>

> Try a quick experiment yourself: copy calc.exe from c:\windows\system32

> to your desktop, run it, and then try and delete calc.exe from your

> desktop--you can't. Same thing if you copy it to a network share

> (a SMB share provided by a windows OS). This is true whether

> on a workstation or server OS.

>

> This is the reason when you apply updates to many popular

> programs they ask you to shutdown the application first. For

> example Adobe Reader will prompt you and then automatically

> close the running instance of Reader so that it can update to a

> new version.

>

> You have found a method to circumvent correct locking behavior.

> Think about it for a moment: what good is having a lock on a file

> if someone can come along and replace the entire file at will? I

> don't know why Samba/Linux allows you to do this.

>

> I am very familar with the problem. You have an in-house application

> that you need/want to update during the day when people are

> working. The trouble is you can't do it until all users have exited

> the application.

>

> The way I have tackled it in the past is to have an app shutdown/restart

> capability built-in to my code. I have an admin console of the program

> which signals the running instances of the application to close and run a

> different exe. This different exe waits for the main exe to be replaced

> and then automatically restarts the new version of the main app.

>

> In another case I created a program that would terminate all running

> instances on the network of a particular application so that maintenance

> could be performed. I did not have access to the source code. This

> was *not* dangerous because I analyzed the application, tested, and

> determined that the termination would not cause data loss.

>

> Thanks.

>

> -TP

>

> Toni Van Remortel wrote:

>> We use Samba Version 3.0.28a.

>> The file state on the app on the server is:

>> DENY_WRITE 0xa1 RDONLY

>>

>> The way to upgrade our app is by overwriting the version on the

>> server (not through Samba, but through SSH on Linux) and ask the

>> users to close and open the app again. Works like a charm.

>>

>> PS: We have no problems on workstations. And as far as I'm following

>> the story right now, a user that closes the app should equal closing

>> the app by all TS users (which still doesn't clear the 'shared

>> memory'). Still not the same story.

 

--

Regards,

Toni Van Remortel

[Guest TP]

Re: Application caching

 

Hi Tony,

 

First, recognize that by breaking the locking contract you

are asking for unpredicatable behavior by definition. In

some cases you may be happy with the results, in other

cases you may not.

 

One difference between the workstations and the TS is

that you are not opening multiple instances of the exe

at the same time on each workstation.

 

My guesspectation as to the behavior of the TS (in your

scenario) would be at a minimum *all* instances of the exe

would need to be terminated before the new app version

would load. This makes sense because the exe is in the

cache *once* and used by the different sessions.

 

Did you verify via Task Manager that there were no

instances of the exe still loaded in memory? A user could

close the app properly but it still remain running with no

visible window. If they logout the instance would terminate.

 

Did you use Process Explorer to verify that there were

no open file handles to the exe on the NAS (after all

instances were terminated)?

 

One thing I would suggest is to create unique shares for

each TS user/session (I assume you are limiting each user

to one session). Each TS user would run the exe from

their unique share name instead of using the same share

name as the other sessions.

 

All of the shares would in reality point to the same folder

with the same exe. The key difference is that windows

would treat them as unique files. Keep in mind this will

increase the memory use on the TS.

 

Please let us know what you work out.

 

Thanks.

 

-TP

 

Toni Van Remortel wrote:

> Hi TP,

>

> Thanks for your explanation about the locking mechanism. I know this

> method, and I'm aware of it's function.

> We do go around the locking of the exe on Linux to make our lives

> easier (just send a mail to the users telling them to restart the app

> when they want to, to get the new version). It works perfectly in a

> workstation environment.

>

> But that still doesn't explain why the old app is openend on the

> Terminal Server if ALL TS users have closed it. It only disappears

> when ALL TS users log out of TS (while workstation users don't need

> to log out to get the new app, tehy only need to close it and reopen

> it).

> That is my concern. If nobody has the app open, why is the old app

> still coming back?

>

> In my view, there is no difference between a single workstation and a

> Terminal Server. If every TS users closes the app, it should resemble

> the same situation as if the workstation user closes the app. I have

> no clue why Terminal Server would keep the old app in memory, while a

> workstation doesn't.

>

> Regards,

> Toni

[Guest TP]

Re: Application caching

 

Sorry, I meant:

 

Hi Toni,

 

-TP

[Guest Toni Van Remortel]

Re: Application caching

 

Hi TP,

 

Thanks for the explanation, that makes much sense.

When we have an update again, I'll try to see what will happen on the

Terminal Server.

BTW: on the current project, we update the application in the users night

(we are in Belgium, Terminal Server is in Malaysia for users in Singapore).

 

Regards,

Toni

 

TP wrote:

> Hi Tony,

>

> First, recognize that by breaking the locking contract you

> are asking for unpredicatable behavior by definition. In

> some cases you may be happy with the results, in other

> cases you may not.

>

> One difference between the workstations and the TS is

> that you are not opening multiple instances of the exe

> at the same time on each workstation.

>

> My guesspectation as to the behavior of the TS (in your

> scenario) would be at a minimum *all* instances of the exe

> would need to be terminated before the new app version

> would load. This makes sense because the exe is in the

> cache *once* and used by the different sessions.

>

> Did you verify via Task Manager that there were no

> instances of the exe still loaded in memory? A user could

> close the app properly but it still remain running with no

> visible window. If they logout the instance would terminate.

>

> Did you use Process Explorer to verify that there were

> no open file handles to the exe on the NAS (after all

> instances were terminated)?

>

> One thing I would suggest is to create unique shares for

> each TS user/session (I assume you are limiting each user

> to one session). Each TS user would run the exe from

> their unique share name instead of using the same share

> name as the other sessions.

>

> All of the shares would in reality point to the same folder

> with the same exe. The key difference is that windows

> would treat them as unique files. Keep in mind this will

> increase the memory use on the TS.

>

> Please let us know what you work out.

>

> Thanks.

>

> -TP

>

> Toni Van Remortel wrote:

>> Hi TP,

>>

>> Thanks for your explanation about the locking mechanism. I know this

>> method, and I'm aware of it's function.

>> We do go around the locking of the exe on Linux to make our lives

>> easier (just send a mail to the users telling them to restart the app

>> when they want to, to get the new version). It works perfectly in a

>> workstation environment.

>>

>> But that still doesn't explain why the old app is openend on the

>> Terminal Server if ALL TS users have closed it. It only disappears

>> when ALL TS users log out of TS (while workstation users don't need

>> to log out to get the new app, tehy only need to close it and reopen

>> it).

>> That is my concern. If nobody has the app open, why is the old app

>> still coming back?

>>

>> In my view, there is no difference between a single workstation and a

>> Terminal Server. If every TS users closes the app, it should resemble

>> the same situation as if the workstation user closes the app. I have

>> no clue why Terminal Server would keep the old app in memory, while a

>> workstation doesn't.

>>

>> Regards,

>> Toni

 

--

Regards,

Toni Van Remortel