Thanks Darren Unfortunately we are indeed clearing cached profiles at logoff and so download of roaming profiles is gonna take some time. We store a lot of files specially for lotus notes so I could have done without that. I am gonna need to think a bit about this one. But at this stage I'd rather take a hit at logon/logoff and have a reasonably well performant session than crap performance all throughout the session.
Thanks to all others that replied too. Cheers M@ On 7/8/06, Darren Mar-Elia <[EMAIL PROTECTED]> wrote:
In general I recommend against AppData redirection for the performance reasons you've already cited below. A lot of apps, esp. MS apps, read/write to files in AppData frequently as they run, and I've just found that when that data resides remotely, it really slows down the user's experience. If you are concerned about download performance of roaming profiles, you could set AppData to not roam, but that won't do you much good in a TS environment. Keep in mind also that unless your users are moving around to a lot of different machines, the roaming profile hit should be reasonably minimal after the initial download because the roaming profile algorithm should only be downloading changed files. Of course, all bets are off if you're deleting the cached profile at each logoff (as may be the case on a TS). Darren -----Original Message----- Wrom: MHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDX [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Saturday, July 08, 2006 10:57 AM To: [email protected] Subject: Re: [ActiveDir] Fwd: Redirect Application Data Basically the reason I am inquiring this is because of performance issues which were blamed on application redirection. The appdata was on a cluster in this particular instance. Siting the fact that there are more components involved in the data path when appdata is accessed from a cluster , the PSS guy basically didnt personally seem to approve the design. And it seems like quite a few guys share his opinion. As he explained, in a normal file server the client will go through the file server's nic, the ide/scsi controller and then to the disk(s). In a cluster environment, the client goes through the cluster node's nic, the node's HBA, fibre switch/hub, SAN controller, and finally disk(s). And in the case of small files the SAN was not very performant especially with big volumes with lots of files. In the webcast I mentioned in the original email, in slide 22 of the presentation available at http://www.microsoft.com/emea/itsshowtime/sessionh.aspx?videoid=26 for group policy tips and tricks Mark Cribben recommends against it. I would say the main reason for that recommendation is network latency. We are designing some file servers at the moment for the client and we have some design considerations and fears. Basically we are wondering whether to do away with appdata redirection altogether and leave it in the profile itself. One of the suggestions is that we may take a hit in logon time to download profiles , but app performance will be good as the files are cached locally during the TS session. We would like to use appdata redirection if at all possible. But we dont want to sacrifice app performance for it. i.e. We dont want to wait too long while the app is looking for ini files etc.. Thoughts? M@ On 7/8/06, Susan Bradley <[EMAIL PROTECTED]> wrote: > > Sorry read the original post and saw it was specifically about TS. > > TS is one of those things that if the application loves the TS > environment, I don't think we've seen too many issues... and that's usually the key... > there are some applications that just don't work well and the vendor > states so in a TS/Citrix setup and would have problems redirecting. > > I know that we redirect 'normal' stuff like My Docs folder all the > time over a TS... but apps like Word and Excel don't have to maintain > a constant connection to a data file. > > > Susan Bradley <[EMAIL PROTECTED]> wrote: > Please correct me if I'm wrong.. but in the era of Howard/LeBlanc and > Howard/Lipner's Secure Coding and SDL books.... currently written > software from Microsoft is indeed following their "best practice" guidelines. > > (Which my only complaint wtih both books is that they are paperback > and not hardbound and thusly when I throw them at crappy app developers like ... > oh.. say.. I don't know....Intuit... the bruise on the head of the Dev > folks there will be slightly lessened.... the SDL book so far is very > interesting....) > > Older software that they purchased .. granted that statement cannot be > made... > > And isn't your situation solvable with having on your patch test > matrix a check box that says "ensure app data redirect is still > functional"... and of course testing that patch before it's globally deployed? > > Matt Hargraves <[EMAIL PROTECTED]> wrote: > I believe the reason they recommend against this is because all > applications are different. Another problem is that there is no > guarantee that the application will remain the same. Patches and > updates can change more than just a file here and a file there, they > can change settings such as these and trying to redirect the location > for that data can end up with a situation where the application during > an update is trying to pull your information from %userroot%\appname > and it's really at a completely different location. > > If all application vendors use MS best practices for programming, it > would be great, but unfortunately not even MS always uses their own > best practices. > > Redirecting application data can work fine for months or even years, > but then you get an update to an application and *bam* everything's > broken and you don't really know why and you spend days (or worse, > weeks) trying to figure out why everyone's broken and realize that > your problem is that the application data is being redirected and that's the source of the problem. > > Matt > > > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
