Migrating to Windows Server 2008 terminal servers has been the most painful Microsoft-product-orientated experience of my life!
In the first of many questions that I hope I can get assistance with...
Is it possible to re-direct the users' locally cached profile to another drive? In a supported manner?
We tend to see heavy fragmentation on the C: drive (causing performance degredation) and there is always the danger that the C: drive could be filled if roaming profiles are not deleted at log off (preventing the use of a performance enhancer).
Or am I missing something? Why is it no-one else is concerned with file fragmentation or full disks? Is there something I should be doing that would mitigate against these problems? I know I can enable the deletion of cached profiles on exit - is this something that is the norm? I understand that deletion of the cached content would mitigate the disk space issue but is this seen as adequate protection against file fragmentation?
With a single c: drive, if you run out of space, you have other issues going on. If your afraid of the c: drive going full on single partition, how would you even begin to cope with it split into partitions? as for fragmentation, how much do you expect to be changing on the server? The page file should only be one size an dshould never be allowed to expand or contract on its own. As well, there should be very little if any actual data on the server itself which cuts down on fragmentation immensely. As for profiles, that would be the only real cause of fragmentation and that should be minimal at best. an occasional defrag should easily take care of that.
For the record in case anyone else is browsing for the answer you change the following REG Key, any new profiles are created in the specified directory.
Defrag performance is a hotly debated topic on whether it's an actual problem or not. I'll leave that for you to decide on your own experiences.
as for filling the drive, most people don't put artificial limitations on the C: drive. You typically don't partition the drives. you typically only have a c: drive so there is no filling problem.
That does seem a little at odds with my understanding of the best practice advice - I thought it was recommended to split the system files from the page file, from the log files, from the user data? I know that there would be no benefit in terms of I/O throughput if all these partitions were simply seperate partitions on the same physical disks but wouldn't this minimise the potential for fragmentation and potential DoS resulting from a full system disk?
I fear that we are not running on the most suitable hardware and that it is the disks that may prove to be our bottleneck. :(
With a single c: drive, if you run out of space, you have other issues going on. If your afraid of the c: drive going full on single partition, how would you even begin to cope with it split into partitions? as for fragmentation, how much do you expect to be changing on the server? The page file should only be one size an dshould never be allowed to expand or contract on its own. As well, there should be very little if any actual data on the server itself which cuts down on fragmentation immensely. As for profiles, that would be the only real cause of fragmentation and that should be minimal at best. an occasional defrag should easily take care of that.
We have a 72GB (soon to be increased to 146GB) mirrored partition (we're using HP blade servers which is quite restrictive in terms of physical disks) and we have manually set and fixed the page file to 12GB (servers have 12GB RAM installed). Maybe it was just a result of our servers dropping like flies (BSoD*) that resulted in the high disk space usage (users not logging off so their temporary files are not being nuked).
It is somewhat reassuring to know that others are running with their local users' profile cached on the C: drive - it has been bugging me for some time.
Thanks again Jeff.
* After installing a couple of the latest Windows Server 2008 hotfixes most of our BSoD crashes have all but gone - although we are still plagued with random lockups necessitating reboots! :(
For the record in case anyone else is browsing for the answer you change the following REG Key, any new profiles are created in the specified directory.
For the record in case anyone else is browsing for the answer you change the following REG Key, any new profiles are created in the specified directory.
