Is the physical security of the server so poor that you're using encryption to protect the data at rest? That's about the only situation I can see using encryption on a server which then shares that data.
On Wed, Mar 30, 2011 at 1:34 PM, Carl Houseman <c.house...@gmail.com> wrote: > Recently set up some encrypted storage on an SBS 2003 server using > Truecrypt, just a simple encrypted container, no encryption of system > drive. The server is also running AVG 9 but the Truecrypt container folder > has been excluded from RT scanning. Two folders on the encrypted volume > have been shared to the network for access by XP client machines. I've done > this on a Server 2003 without incident, but that server wasn't running any > AV. > > > > Since Truecrypt was set up there have been 4 BSOD's, 3 of them were > x1000007e (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) but one 0x00000035 > (NO_MORE_IRP_STACK_LOCATIONS), all referencing *srv.sys*. All of the > BSODs coincide with clients accessing the share(s) on the encrypted volume. > It could be reading or writing For the case of the 0x35, I increased the > DfsIRPStackSize for MUP.sys even though the BSOD wasn't complaining about > MUP.sys. Can't tell yet if that helped or not (there's only been one BSOD > since, it was today's 7e). > > > > So, I'm hoping somebody else has heard of this, but not that hopeful since > Google hasn't heard of it. I know I can open an incident at Truecrypt.org. > > > > Meanwhile, I'm probably going to scrap Truecrypt and try FreeOTFE and hope > that makes a difference. Since both are open source, can I reasonably hope > they are using different code that might be related to these crashes? > > > > Or if you have a preferred alternative for a (a) free means of (b) > encrypting a subset of server storage so that storage is (c) available to > network client users (d) without them thinking about it or having to type > anything (other than entering the decryption password one time after each > server restart), and that encryption (e) doesn't need or recommend the use > of complex recovery mechanisms, and (f) know about or have a set-up tutorial > for said encryption that is (g) faster to work through than setting up > FreeOTFE, I'm all ears. > > > > [The (a) ... (g) in the above paragraph are required conditions for an > alternative to overtake FreeOTFE as the next attempt at making this work... > I'm open to all suggestions, but I have limited time with which to solve > this and FreeOTFE looks like the least trouble to try.] > > > > TIA > > Carl > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
