none
Remote App - saving files locally are extremely slow RRS feed

  • Question

  • Looking for workarounds or if I am just doing something silly.  Currently we are piloting a few remote locations and using Office 2007 on a TS Farm via Remote Apps.  The apps launch fine and are responsive.  However, when we want them to save a file locally, it appears that it saves by using \\tsclient\c\documents\etc.  It appears that when they Save a local file, it is basically being uploaded through the TS server, then back down to the local computer which for large files on these locations with limited bandwidth, its taking very long for even 10-15mb files to save.

    What are my options? And is this expected behavior with Remote App?  Thanks!

    Thursday, December 17, 2009 4:34 PM

Answers

  • Hi withersd,

    Sounds like this is going to be expected behavior. 

    What happens, is your client in the remote office opens a remoteapp, and then opens document (assume this is a document sitting on their local machine in the remote office). This file is then in memory on the terminal server and stays there until the doc is saved/closed. When it is saved, you are saving to a redirected drive (\\tsclient...), via virtual channels. This essentially means, a file is going from the terminal server to the client over the WAN (it is not goign to the temrinal server first when saving, because it is already there).  If the file is large, its gonna take a while.

    Now.  IF your remote offices are actually connected to the main network (where the terminal server is) by say nailed up VPNs, you can try mapping a drive in the terminal server session to a shared drive on the clients local computer, and saving the file to the mapped drive. This would be saving the file using TCP. And it might be faster.  But this wont work if you are instead going through TS Gateway.

    Another option is to have users save files to a file server that is on the same network as the terminal server.
    Hope this helps,

    Kristin L. Griffin

    Co-Author of the Windows Server 2008 Terminal Services Resource Kit (and a SUPER BIG fan of the Microsoft RDV Team!!!) 
    Thursday, December 17, 2009 7:15 PM
    Moderator
  • Because a remoteApp is still a connection on the terminal server, the drive should be mapped on the terminal server.

    Try this out with full desktop sessions so you can tell what is goin gone easily.

    Also test file save to this location from local workstations to make sure you dont have some sort of issue there.


    Hope this helps,

    Kristin L. Griffin

    Co-Author of the Windows Server 2008 Terminal Services Resource Kit (and a SUPER BIG fan of the Microsoft RDV Team!!!) 
    Thursday, December 17, 2009 10:11 PM
    Moderator

All replies

  • Hi withersd,

    Sounds like this is going to be expected behavior. 

    What happens, is your client in the remote office opens a remoteapp, and then opens document (assume this is a document sitting on their local machine in the remote office). This file is then in memory on the terminal server and stays there until the doc is saved/closed. When it is saved, you are saving to a redirected drive (\\tsclient...), via virtual channels. This essentially means, a file is going from the terminal server to the client over the WAN (it is not goign to the temrinal server first when saving, because it is already there).  If the file is large, its gonna take a while.

    Now.  IF your remote offices are actually connected to the main network (where the terminal server is) by say nailed up VPNs, you can try mapping a drive in the terminal server session to a shared drive on the clients local computer, and saving the file to the mapped drive. This would be saving the file using TCP. And it might be faster.  But this wont work if you are instead going through TS Gateway.

    Another option is to have users save files to a file server that is on the same network as the terminal server.
    Hope this helps,

    Kristin L. Griffin

    Co-Author of the Windows Server 2008 Terminal Services Resource Kit (and a SUPER BIG fan of the Microsoft RDV Team!!!) 
    Thursday, December 17, 2009 7:15 PM
    Moderator
  • That does answer most of my question.

    These locations are perm VPNd so I should also mention, since you offered the suggestion about saving files to a file server on the same network as the TS, we attempted saving locally because we experience the same if not worse performance when the user is saving to a file server that is local to the terminal server.

    Would this be because their login script maps U: locally, then when they launch the TS app it is using that mapped drive redirected from the local client instead of from the local fileserver?  Meaning, Should i have the drive map within the TS app, and not on the users desktop when they first log into their system?
    Example.

    User A opens up Excel over TS, has a U: drive mapped to a file server that is local to the TS where the app is being run.   Saving files to that U: even tho the mapped share is local to the TS server is extremely slow.

    Thursday, December 17, 2009 7:29 PM
  • Because a remoteApp is still a connection on the terminal server, the drive should be mapped on the terminal server.

    Try this out with full desktop sessions so you can tell what is goin gone easily.

    Also test file save to this location from local workstations to make sure you dont have some sort of issue there.


    Hope this helps,

    Kristin L. Griffin

    Co-Author of the Windows Server 2008 Terminal Services Resource Kit (and a SUPER BIG fan of the Microsoft RDV Team!!!) 
    Thursday, December 17, 2009 10:11 PM
    Moderator