Guest Toni Van Remortel Posted July 11, 2008 Posted July 11, 2008 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 Posted July 11, 2008 Posted July 11, 2008 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 Posted July 11, 2008 Posted July 11, 2008 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 Posted July 11, 2008 Posted July 11, 2008 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 Posted July 11, 2008 Posted July 11, 2008 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 Posted July 11, 2008 Posted July 11, 2008 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 Posted July 14, 2008 Posted July 14, 2008 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 Posted July 14, 2008 Posted July 14, 2008 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 Posted July 15, 2008 Posted July 15, 2008 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 Posted July 15, 2008 Posted July 15, 2008 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 Posted July 15, 2008 Posted July 15, 2008 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 Posted July 15, 2008 Posted July 15, 2008 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 Posted July 15, 2008 Posted July 15, 2008 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 Posted July 16, 2008 Posted July 16, 2008 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 Posted July 17, 2008 Posted July 17, 2008 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 Posted July 17, 2008 Posted July 17, 2008 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 Posted July 22, 2008 Posted July 22, 2008 Re: Application caching You are welcome Jeff. -TP Jeff Pitsch wrote: > Thanks TP. > > Jeff Pitsch > Microsoft MVP - Terminal Services
Guest Toni Van Remortel Posted July 28, 2008 Posted July 28, 2008 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 Posted July 30, 2008 Posted July 30, 2008 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 Posted July 30, 2008 Posted July 30, 2008 Re: Application caching Sorry, I meant: Hi Toni, -TP
Guest Toni Van Remortel Posted July 31, 2008 Posted July 31, 2008 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
Recommended Posts