The "blue screen" is certainly not true with any recent version of Windows Server.
"Way back when", large numbers of SMB connections could cause the Server service to deplete all available non-paged pool memory. That could lead to a blue screen. But that has nothing to do with why PSTs aren't supported on SMB shares. For performance, the PST store provider reads (and generates a read-lock) on fairly large chunks of the PST. When it wants to update that chunk, it requests a write-lock on only the piece of that area it wants to update. SMB doesn't support a "partial row write-lock". It simulates this by saying "sure", even though it doesn't do it. This CAN lead to corruption of the PST, as there are operations that the PST provider executes that depend on locked areas being, well, locked. There have been updates to the PST provider over the years to minimize these types of lock contentions, but they apparently still exist, and as a PST is used more and more they are more likely to occur. ________________________________________ From: Ben Scott [[email protected]] Sent: Friday, October 23, 2009 11:33 AM To: NT System Admin Issues Subject: Re: HP StorageWorks X1600 Network Storage System On Fri, Oct 23, 2009 at 8:55 AM, John Aldrich <[email protected]> wrote: > ... shouldn’t have anything “important” on the local PC, > except for their email PST files.) One thing you may want to consider is a NAS which can expose SMB shares and yet won't explode if you put PSTs on them. (Microsoft says PSTs on Windows server will eventually cause the server to bluescreen, and that seems to be the case. On the other hand, many years ago I had a few customers hosting their PSTs on a Linux Samba server, and it never complained.) -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
