Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003?
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 x107e (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) but one 0x0035 (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
RE: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003?
Yes and nothing will change that. The data must remain reasonably secure if the server is stolen. From: Jonathan Link [mailto:jonathan.l...@gmail.com] Sent: Wednesday, March 30, 2011 1:39 PM To: NT System Admin Issues Subject: Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? 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 x107e (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) but one 0x0035 (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 ~ 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
Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003?
Nope, I haven't seen that problem, although I am not using TrueCrypt on SBS 2003, just Windows 2003, Win7, Win2008 R2 *ASB *(Professional Bio http://about.me/Andrew.S.Baker/bio) *Technology Services that Maximize Business Results... * 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 x107e (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) but one 0x0035 (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
Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003?
My condolences. Were I in your shoes, I'd pull AVG off the server for a few days. Also, can you actually replicate the problem if you revert to the original DfsIRPStackSize for MUP? You can then test whether or not it really is an AVG/Truecrypt problem. On Wed, Mar 30, 2011 at 1:45 PM, Carl Houseman c.house...@gmail.com wrote: Yes and nothing will change that. The data must remain reasonably secure if the server is stolen. *From:* Jonathan Link [mailto:jonathan.l...@gmail.com] *Sent:* Wednesday, March 30, 2011 1:39 PM *To:* NT System Admin Issues *Subject:* Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? 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 x107e (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) but one 0x0035 (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 ~ 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
RE: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003?
Lots of customers have data-at-rest encryption requirements. Otherwise, Microsoft wouldn't have bothered to develop BitLocker. :) Regards, Michael B. Smith Consultant and Exchange MVP http://TheEssentialExchange.com From: Jonathan Link [mailto:jonathan.l...@gmail.com] Sent: Wednesday, March 30, 2011 2:00 PM To: NT System Admin Issues Subject: Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? My condolences. Were I in your shoes, I'd pull AVG off the server for a few days. Also, can you actually replicate the problem if you revert to the original DfsIRPStackSize for MUP? You can then test whether or not it really is an AVG/Truecrypt problem. On Wed, Mar 30, 2011 at 1:45 PM, Carl Houseman c.house...@gmail.commailto:c.house...@gmail.com wrote: Yes and nothing will change that. The data must remain reasonably secure if the server is stolen. From: Jonathan Link [mailto:jonathan.l...@gmail.commailto:jonathan.l...@gmail.com] Sent: Wednesday, March 30, 2011 1:39 PM To: NT System Admin Issues Subject: Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? 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.commailto: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 x107e (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) but one 0x0035 (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.commailto: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.commailto: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.commailto: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
Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003?
So, is this your roundabout recommendation of suggesting an upgrade? :-) IIRC Bitlocker wasn't available for SBS 2003 On Wed, Mar 30, 2011 at 2:02 PM, Michael B. Smith mich...@smithcons.comwrote: Lots of customers have data-at-rest encryption requirements. Otherwise, Microsoft wouldn’t have bothered to develop BitLocker. J Regards, Michael B. Smith Consultant and Exchange MVP http://TheEssentialExchange.com http://theessentialexchange.com/ *From:* Jonathan Link [mailto:jonathan.l...@gmail.com] *Sent:* Wednesday, March 30, 2011 2:00 PM *To:* NT System Admin Issues *Subject:* Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? My condolences. Were I in your shoes, I'd pull AVG off the server for a few days. Also, can you actually replicate the problem if you revert to the original DfsIRPStackSize for MUP? You can then test whether or not it really is an AVG/Truecrypt problem. On Wed, Mar 30, 2011 at 1:45 PM, Carl Houseman c.house...@gmail.com wrote: Yes and nothing will change that. The data must remain reasonably secure if the server is stolen. *From:* Jonathan Link [mailto:jonathan.l...@gmail.com] *Sent:* Wednesday, March 30, 2011 1:39 PM *To:* NT System Admin Issues *Subject:* Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? 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 x107e (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) but one 0x0035 (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 ~ 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
RE: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003?
One may choose to read into it whatever one's heart desires. :-) Sent from my HTC Tilt™ 2, a Windows® phone from ATT From: Jonathan Link jonathan.l...@gmail.com Sent: Wednesday, March 30, 2011 2:12 PM To: NT System Admin Issues ntsysadmin@lyris.sunbelt-software.com Subject: Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? So, is this your roundabout recommendation of suggesting an upgrade? :-) IIRC Bitlocker wasn't available for SBS 2003 On Wed, Mar 30, 2011 at 2:02 PM, Michael B. Smith mich...@smithcons.commailto:mich...@smithcons.com wrote: Lots of customers have data-at-rest encryption requirements. Otherwise, Microsoft wouldn’t have bothered to develop BitLocker. :) Regards, Michael B. Smith Consultant and Exchange MVP http://TheEssentialExchange.comhttp://theessentialexchange.com/ From: Jonathan Link [mailto:jonathan.l...@gmail.commailto:jonathan.l...@gmail.com] Sent: Wednesday, March 30, 2011 2:00 PM To: NT System Admin Issues Subject: Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? My condolences. Were I in your shoes, I'd pull AVG off the server for a few days. Also, can you actually replicate the problem if you revert to the original DfsIRPStackSize for MUP? You can then test whether or not it really is an AVG/Truecrypt problem. On Wed, Mar 30, 2011 at 1:45 PM, Carl Houseman c.house...@gmail.commailto:c.house...@gmail.com wrote: Yes and nothing will change that. The data must remain reasonably secure if the server is stolen. From: Jonathan Link [mailto:jonathan.l...@gmail.commailto:jonathan.l...@gmail.com] Sent: Wednesday, March 30, 2011 1:39 PM To: NT System Admin Issues Subject: Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? 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.commailto: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 x107e (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) but one 0x0035 (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.commailto: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.commailto:listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe
RE: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: FOUO +1 -Original Message- From: Michael B. Smith [mailto:mich...@smithcons.com] Sent: Wednesday, March 30, 2011 2:03 PM To: NT System Admin Issues Subject: RE: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? Lots of customers have data-at-rest encryption requirements. Otherwise, Microsoft wouldn't have bothered to develop BitLocker. :-) Regards, Michael B. Smith Consultant and Exchange MVP http://TheEssentialExchange.com From: Jonathan Link [mailto:jonathan.l...@gmail.com] Sent: Wednesday, March 30, 2011 2:00 PM To: NT System Admin Issues Subject: Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? My condolences. Were I in your shoes, I'd pull AVG off the server for a few days. Also, can you actually replicate the problem if you revert to the original DfsIRPStackSize for MUP? You can then test whether or not it really is an AVG/Truecrypt problem. On Wed, Mar 30, 2011 at 1:45 PM, Carl Houseman c.house...@gmail.com wrote: Yes and nothing will change that. The data must remain reasonably secure if the server is stolen. From: Jonathan Link [mailto:jonathan.l...@gmail.com] Sent: Wednesday, March 30, 2011 1:39 PM To: NT System Admin Issues Subject: Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? 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 x107e (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) but one 0x0035 (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/ blockedhttp://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ blockedhttp://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com blockedmailto: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/ blockedhttp://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ blockedhttp://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com blockedmailto: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/ blockedhttp://www.sunbeltsoftware.com/Business/VIPRE-Enterprise
RE: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003?
Had the 0x35 BSOD before changing DfsIRPStackSize, haven't had one since, but I have had 0x7e BSOD before and after that change. Had the 0x7e BSOD before and after protecting the encrypted container folder from AV RT scans. Now I've disabled all AV RT scans and if it crashes again, I plan to pull off AVG altogether. From: Jonathan Link [mailto:jonathan.l...@gmail.com] Sent: Wednesday, March 30, 2011 2:00 PM To: NT System Admin Issues Subject: Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? My condolences. Were I in your shoes, I'd pull AVG off the server for a few days. Also, can you actually replicate the problem if you revert to the original DfsIRPStackSize for MUP? You can then test whether or not it really is an AVG/Truecrypt problem. On Wed, Mar 30, 2011 at 1:45 PM, Carl Houseman c.house...@gmail.com wrote: Yes and nothing will change that. The data must remain reasonably secure if the server is stolen. From: Jonathan Link [mailto:jonathan.l...@gmail.com] Sent: Wednesday, March 30, 2011 1:39 PM To: NT System Admin Issues Subject: Re: Anyone seen BSOD's when using TrueCrypt 7.0a on SBS 2003? 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 x107e (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) but one 0x0035 (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 ~ 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 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http
