[Cosign-discuss] 503 and stopped app pool
I¹m at a loss what is happening as I set this server up in the same method as another that works fine. The only difference is this is 2008 R2 and the other is 2008, so 64bit vs 32bit. When I hit the site, it eventually spits back a 503. I then go to IIS and find the defaultapppool is stopped. The event log says cosignmodule.dll failed to load the data is in the error, whatever that is supposed to mean. I¹m trying to figure out why the module is failing to load and causing the apppool to die. The system log mentions it reported a listener channel failure, again whatever that means. Any thoughts where I can get more detail what is failing? Thanks, Yadin --- Yadin Flammer - Systems Administrator College of Arts & Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] 503 and stopped app pool
Yadin, Sounds like you are having the same issues on Win 2008 R2 that we were seeing. One temporary quick fix is to increase the specific Application Pool's Rapid-Fail Protection settings under Advanced Settings. We ended up with 100 Maximum Failures in a 5min Failure Interval. You could just disable Rapid-Fail, but that would be a bad idea. The better long term fix is to get your hands on Cosign Module 3.1.0 RC2. This release candidate has seemed to fixed our problems with Cosign crashing the IIS 7.5 application pool. It is my understanding that an official updated production release is coming. Thanks... David Stucky, CISSP, GSEC Systems Security Analyst Office of Human Resources Information Systems 503 James M. Elliott Building 814-865-4049 d...@psu.edu<mailto:d...@psu.edu> From: Yadin Flammer [mailto:y...@psu.edu] Sent: Thursday, August 25, 2011 6:47 PM To: cosign-discuss@lists.sourceforge.net Subject: [Cosign-discuss] 503 and stopped app pool I'm at a loss what is happening as I set this server up in the same method as another that works fine. The only difference is this is 2008 R2 and the other is 2008, so 64bit vs 32bit. When I hit the site, it eventually spits back a 503. I then go to IIS and find the defaultapppool is stopped. The event log says cosignmodule.dll failed to load the data is in the error, whatever that is supposed to mean. I'm trying to figure out why the module is failing to load and causing the apppool to die. The system log mentions it reported a listener channel failure, again whatever that means. Any thoughts where I can get more detail what is failing? Thanks, Yadin --- Yadin Flammer - Systems Administrator College of Arts & Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] 503 and stopped app pool
I should add the only reason we had to set the Rapid-Fail Protect temporally that high was because we were inadvertently hammering the issue with a Web Application Security Scan that was causing cosign to cash the IIS 7.5 web application pool 50+ times in 20-30secs. You mileage may vary. Thanks... David Stucky, CISSP, GSEC Systems Security Analyst Office of Human Resources Information Systems 503 James M. Elliott Building 814-865-4049 d...@psu.edu<mailto:d...@psu.edu> From: Stucky, David [mailto:d...@psu.edu] Sent: Friday, August 26, 2011 9:31 AM To: Yadin Flammer; cosign-discuss@lists.sourceforge.net Subject: Re: [Cosign-discuss] 503 and stopped app pool Yadin, Sounds like you are having the same issues on Win 2008 R2 that we were seeing. One temporary quick fix is to increase the specific Application Pool's Rapid-Fail Protection settings under Advanced Settings. We ended up with 100 Maximum Failures in a 5min Failure Interval. You could just disable Rapid-Fail, but that would be a bad idea. The better long term fix is to get your hands on Cosign Module 3.1.0 RC2. This release candidate has seemed to fixed our problems with Cosign crashing the IIS 7.5 application pool. It is my understanding that an official updated production release is coming. Thanks... David Stucky, CISSP, GSEC Systems Security Analyst Office of Human Resources Information Systems 503 James M. Elliott Building 814-865-4049 d...@psu.edu<mailto:d...@psu.edu> From: Yadin Flammer [mailto:y...@psu.edu] Sent: Thursday, August 25, 2011 6:47 PM To: cosign-discuss@lists.sourceforge.net Subject: [Cosign-discuss] 503 and stopped app pool I'm at a loss what is happening as I set this server up in the same method as another that works fine. The only difference is this is 2008 R2 and the other is 2008, so 64bit vs 32bit. When I hit the site, it eventually spits back a 503. I then go to IIS and find the defaultapppool is stopped. The event log says cosignmodule.dll failed to load the data is in the error, whatever that is supposed to mean. I'm trying to figure out why the module is failing to load and causing the apppool to die. The system log mentions it reported a listener channel failure, again whatever that means. Any thoughts where I can get more detail what is failing? Thanks, Yadin --- Yadin Flammer - Systems Administrator College of Arts & Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] 503 and stopped app pool
Am I to gather that the main release 3.03 simply does not work in 2008 R2? I¹m seeing there are significant configuration and behavioral differences in IIS from 2008, and when I try to make things match up they invariably revert themselves. The DefaultAppPool for example is set to Classic and ApplicationPoolIdentity instead of Integrated and NetworkService like in 2008. Trying to change those only sticks for a short while, then it reverts itself back. I¹ve also at one person¹s recommendation tried to disable 32bit applications in the pool, but invariably that re-enables itself as well. This does of course lead me to question if there are huge bugs in IIS in R2, or if there are other forces at work reverting these that I¹m not aware of. I also find that having the key under the section added to the applicationHost.config causes the 503 to go away because it causes the module to become unregistered and therefore not used. If I have this line in place but leave it as the example instead of setting it for our location, then it doesn¹t unload the module, but the app pool shutdown and 503 issue continues. So yea... Any other ideas or do I need to just move to the beta 3.1 because it¹s more stable than the release 3.03? The rapid fail doesn¹t do anything unfortunately, other than make the failure take longer and fill the event viewer. Thanks, Yadin On 8/26/11 9:31 AM, "Stucky, David" wrote: > Yadin, > > Sounds like you are having the same issues on Win 2008 R2 that we were seeing. > One temporary quick fix is to increase the specific Application Pool¹s > Rapid-Fail Protection settings under Advanced Settings. We ended up with 100 > Maximum Failures in a 5min Failure Interval. You could just disable > Rapid-Fail, but that would be a bad idea. > > The better long term fix is to get your hands on Cosign Module 3.1.0 RC2. > This release candidate has seemed to fixed our problems with Cosign crashing > the IIS 7.5 application pool. It is my understanding that an official updated > production release is coming. > > > > > Thanks > > David Stucky, CISSP, GSEC > Systems Security Analyst > Office of Human Resources > Information Systems > 503 James M. Elliott Building > > 814-865-4049 > d...@psu.edu > > > From: Yadin Flammer [mailto:y...@psu.edu] > Sent: Thursday, August 25, 2011 6:47 PM > To: cosign-discuss@lists.sourceforge.net > Subject: [Cosign-discuss] 503 and stopped app pool > > I¹m at a loss what is happening as I set this server up in the same method as > another that works fine. The only difference is this is 2008 R2 and the other > is 2008, so 64bit vs 32bit. When I hit the site, it eventually spits back a > 503. I then go to IIS and find the defaultapppool is stopped. The event log > says cosignmodule.dll failed to load the data is in the error, whatever that > is supposed to mean. I¹m trying to figure out why the module is failing to > load and causing the apppool to die. The system log mentions it reported a > listener channel failure, again whatever that means. > > Any thoughts where I can get more detail what is failing? > Thanks, > Yadin > > > --- > Yadin Flammer - Systems Administrator > College of Arts & Architecture, Penn State University > 228 Borland Building Office Phone: 814-865-0990 > University Park, PA 16802 Dept. Phone: 814-865-1571 > Email: y...@psu.edu Dept. Fax:814-863-6227 > --- Yadin Flammer - Systems Administrator College of Arts & Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] 503 and stopped app pool
Well unfortunately 3.1 doesn¹t change anything, it still doesn¹t work. I also tried the 32bit module on a whim and same issue. I¹m totally lost as to why it ³fails to load² when you hit the website and shuts down the default app pool causing a 503. Is there any log that will tell me something more useful than ³the data is in the error²? On 8/26/11 12:09 PM, "Yadin Flammer" wrote: > Am I to gather that the main release 3.03 simply does not work in 2008 R2? > I¹m seeing there are significant configuration and behavioral differences in > IIS from 2008, and when I try to make things match up they invariably revert > themselves. The DefaultAppPool for example is set to Classic and > ApplicationPoolIdentity instead of Integrated and NetworkService like in 2008. > Trying to change those only sticks for a short while, then it reverts itself > back. I¹ve also at one person¹s recommendation tried to disable 32bit > applications in the pool, but invariably that re-enables itself as well. This > does of course lead me to question if there are huge bugs in IIS in R2, or if > there are other forces at work reverting these that I¹m not aware of. > > I also find that having the key under the section added > to the applicationHost.config causes the 503 to go away because it causes the > module to become unregistered and therefore not used. If I have this line in > place but leave it as the example instead of setting it for our location, then > it doesn¹t unload the module, but the app pool shutdown and 503 issue > continues. > > So yea... Any other ideas or do I need to just move to the beta 3.1 because > it¹s more stable than the release 3.03? The rapid fail doesn¹t do anything > unfortunately, other than make the failure take longer and fill the event > viewer. > > Thanks, > Yadin > > > On 8/26/11 9:31 AM, "Stucky, David" wrote: > >> Yadin, >> >> Sounds like you are having the same issues on Win 2008 R2 that we were >> seeing. One temporary quick fix is to increase the specific Application >> Pool¹s Rapid-Fail Protection settings under Advanced Settings. We ended up >> with 100 Maximum Failures in a 5min Failure Interval. You could just disable >> Rapid-Fail, but that would be a bad idea. >> >> The better long term fix is to get your hands on Cosign Module 3.1.0 RC2. >> This release candidate has seemed to fixed our problems with Cosign crashing >> the IIS 7.5 application pool. It is my understanding that an official >> updated production release is coming. >> >> >> >> >> Thanks >> >> David Stucky, CISSP, GSEC >> Systems Security Analyst >> Office of Human Resources >> Information Systems >> 503 James M. Elliott Building >> >> 814-865-4049 >> d...@psu.edu >> >> >> From: Yadin Flammer [mailto:y...@psu.edu] >> Sent: Thursday, August 25, 2011 6:47 PM >> To: cosign-discuss@lists.sourceforge.net >> Subject: [Cosign-discuss] 503 and stopped app pool >> >> I¹m at a loss what is happening as I set this server up in the same method as >> another that works fine. The only difference is this is 2008 R2 and the >> other is 2008, so 64bit vs 32bit. When I hit the site, it eventually spits >> back a 503. I then go to IIS and find the defaultapppool is stopped. The >> event log says cosignmodule.dll failed to load the data is in the error, >> whatever that is supposed to mean. I¹m trying to figure out why the module >> is failing to load and causing the apppool to die. The system log mentions >> it reported a listener channel failure, again whatever that means. >> >> Any thoughts where I can get more detail what is failing? >> Thanks, >> Yadin >> >> >> --- >> Yadin Flammer - Systems Administrator >> College of Arts & Architecture, Penn State University >> 228 Borland Building Office Phone: 814-865-0990 >> University Park, PA 16802 Dept. Phone: 814-865-1571 >> Email: y...@psu.edu Dept. Fax:814-863-6227 >> > > --- > Yadin Flammer - Systems Administrator > College of Arts & Architecture, Penn State University > 228 Borland Building Office Phone: 814-865-0990 > University Park, PA 16802 Dept. Phone: 814-865-1571 > Email: y...@psu.edu Dept. Fax:814-863-6227 > > > -- > EMC VNX: the world's simplest storage, startin
Re: [Cosign-discuss] 503 and stopped app pool
Hi Yadin, I think this might help: > I recommend downloading DebugView to see the CosignModule's verbose > output. It should give us a better idea of where the cosignmodule is > failing. > http://technet.microsoft.com/en-us/sysinternals/Utilities/DebugView.ht Jarod sent that to me a while back and it provided helpful info. --Brian Lee Office of New Student Programs Web Admin From: Yadin Flammer [mailto:y...@psu.edu] Sent: Friday, August 26, 2011 12:36 PM To: Yadin Flammer; cosign-discuss@lists.sourceforge.net Subject: Re: [Cosign-discuss] 503 and stopped app pool Well unfortunately 3.1 doesn't change anything, it still doesn't work. I also tried the 32bit module on a whim and same issue. I'm totally lost as to why it "fails to load" when you hit the website and shuts down the default app pool causing a 503. Is there any log that will tell me something more useful than "the data is in the error"? On 8/26/11 12:09 PM, "Yadin Flammer" wrote: Am I to gather that the main release 3.03 simply does not work in 2008 R2? I'm seeing there are significant configuration and behavioral differences in IIS from 2008, and when I try to make things match up they invariably revert themselves. The DefaultAppPool for example is set to Classic and ApplicationPoolIdentity instead of Integrated and NetworkService like in 2008. Trying to change those only sticks for a short while, then it reverts itself back. I've also at one person's recommendation tried to disable 32bit applications in the pool, but invariably that re-enables itself as well. This does of course lead me to question if there are huge bugs in IIS in R2, or if there are other forces at work reverting these that I'm not aware of. I also find that having the key under the section added to the applicationHost.config causes the 503 to go away because it causes the module to become unregistered and therefore not used. If I have this line in place but leave it as the example instead of setting it for our location, then it doesn't unload the module, but the app pool shutdown and 503 issue continues. So yea... Any other ideas or do I need to just move to the beta 3.1 because it's more stable than the release 3.03? The rapid fail doesn't do anything unfortunately, other than make the failure take longer and fill the event viewer. Thanks, Yadin On 8/26/11 9:31 AM, "Stucky, David" wrote: Yadin, Sounds like you are having the same issues on Win 2008 R2 that we were seeing. One temporary quick fix is to increase the specific Application Pool's Rapid-Fail Protection settings under Advanced Settings. We ended up with 100 Maximum Failures in a 5min Failure Interval. You could just disable Rapid-Fail, but that would be a bad idea. The better long term fix is to get your hands on Cosign Module 3.1.0 RC2. This release candidate has seemed to fixed our problems with Cosign crashing the IIS 7.5 application pool. It is my understanding that an official updated production release is coming. Thanks... David Stucky, CISSP, GSEC Systems Security Analyst Office of Human Resources Information Systems 503 James M. Elliott Building 814-865-4049 d...@psu.edu From: Yadin Flammer [mailto:y...@psu.edu] Sent: Thursday, August 25, 2011 6:47 PM To: cosign-discuss@lists.sourceforge.net Subject: [Cosign-discuss] 503 and stopped app pool I'm at a loss what is happening as I set this server up in the same method as another that works fine. The only difference is this is 2008 R2 and the other is 2008, so 64bit vs 32bit. When I hit the site, it eventually spits back a 503. I then go to IIS and find the defaultapppool is stopped. The event log says cosignmodule.dll failed to load the data is in the error, whatever that is supposed to mean. I'm trying to figure out why the module is failing to load and causing the apppool to die. The system log mentions it reported a listener channel failure, again whatever that means. Any thoughts where I can get more detail what is failing? Thanks, Yadin --- Yadin Flammer - Systems Administrator College of Arts & Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 --- Yadin Flammer - Systems Administrator College of Arts & Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 --
Re: [Cosign-discuss] 503 and stopped app pool
Hah! I see that Jarod sent me a corrected URL right afyterward... LOL http://technet.microsoft.com/en-us/sysinternals/bb896647 --Brian Lee Office of New Student Programs Web Admin From: Yadin Flammer [mailto:y...@psu.edu] Sent: Friday, August 26, 2011 12:36 PM To: Yadin Flammer; cosign-discuss@lists.sourceforge.net Subject: Re: [Cosign-discuss] 503 and stopped app pool Well unfortunately 3.1 doesn't change anything, it still doesn't work. I also tried the 32bit module on a whim and same issue. I'm totally lost as to why it "fails to load" when you hit the website and shuts down the default app pool causing a 503. Is there any log that will tell me something more useful than "the data is in the error"? On 8/26/11 12:09 PM, "Yadin Flammer" wrote: Am I to gather that the main release 3.03 simply does not work in 2008 R2? I'm seeing there are significant configuration and behavioral differences in IIS from 2008, and when I try to make things match up they invariably revert themselves. The DefaultAppPool for example is set to Classic and ApplicationPoolIdentity instead of Integrated and NetworkService like in 2008. Trying to change those only sticks for a short while, then it reverts itself back. I've also at one person's recommendation tried to disable 32bit applications in the pool, but invariably that re-enables itself as well. This does of course lead me to question if there are huge bugs in IIS in R2, or if there are other forces at work reverting these that I'm not aware of. I also find that having the key under the section added to the applicationHost.config causes the 503 to go away because it causes the module to become unregistered and therefore not used. If I have this line in place but leave it as the example instead of setting it for our location, then it doesn't unload the module, but the app pool shutdown and 503 issue continues. So yea... Any other ideas or do I need to just move to the beta 3.1 because it's more stable than the release 3.03? The rapid fail doesn't do anything unfortunately, other than make the failure take longer and fill the event viewer. Thanks, Yadin On 8/26/11 9:31 AM, "Stucky, David" wrote: Yadin, Sounds like you are having the same issues on Win 2008 R2 that we were seeing. One temporary quick fix is to increase the specific Application Pool's Rapid-Fail Protection settings under Advanced Settings. We ended up with 100 Maximum Failures in a 5min Failure Interval. You could just disable Rapid-Fail, but that would be a bad idea. The better long term fix is to get your hands on Cosign Module 3.1.0 RC2. This release candidate has seemed to fixed our problems with Cosign crashing the IIS 7.5 application pool. It is my understanding that an official updated production release is coming. Thanks... David Stucky, CISSP, GSEC Systems Security Analyst Office of Human Resources Information Systems 503 James M. Elliott Building 814-865-4049 d...@psu.edu From: Yadin Flammer [mailto:y...@psu.edu] Sent: Thursday, August 25, 2011 6:47 PM To: cosign-discuss@lists.sourceforge.net Subject: [Cosign-discuss] 503 and stopped app pool I'm at a loss what is happening as I set this server up in the same method as another that works fine. The only difference is this is 2008 R2 and the other is 2008, so 64bit vs 32bit. When I hit the site, it eventually spits back a 503. I then go to IIS and find the defaultapppool is stopped. The event log says cosignmodule.dll failed to load the data is in the error, whatever that is supposed to mean. I'm trying to figure out why the module is failing to load and causing the apppool to die. The system log mentions it reported a listener channel failure, again whatever that means. Any thoughts where I can get more detail what is failing? Thanks, Yadin --- Yadin Flammer - Systems Administrator College of Arts & Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 --- Yadin Flammer - Systems Administrator College of Arts & Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http:
Re: [Cosign-discuss] 503 and stopped app pool
Yadin, I misread the details a bit. This is happening every time you browse to your web server? Don't forget to check your web.config file(s) as well I know I can purposely mess that file up to cause crashes every time you hit the server. Maybe re-creating a clean copy of it even if nothing looks wrong. I think is sounds like you just have a configuration file somewhere that is not quite right. In our situation it was only happing very infrequently, so 3.0.3 seemed to work for a while. We would randomly see 5+ Application Pool crashes/reloads in less than 5mins every couple of days on a development server with no high loads. Only when we did our first few web app security scans on a different server did we see a consistent pattern for which 3.1.0 RC2 fixed. Our sporadic crashes/reloads have gone away as well once we dropped in RC2 on our webservers. BTW, we have multiple instances of CF9 installed on the web servers as well just to make things even more complicated. Thanks... David Stucky, CISSP, GSEC Systems Security Analyst Office of Human Resources Information Systems 503 James M. Elliott Building 814-865-4049 d...@psu.edu<mailto:d...@psu.edu> From: Yadin Flammer [mailto:y...@psu.edu] Sent: Friday, August 26, 2011 12:36 PM To: Yadin Flammer; cosign-discuss@lists.sourceforge.net Subject: Re: [Cosign-discuss] 503 and stopped app pool Well unfortunately 3.1 doesn't change anything, it still doesn't work. I also tried the 32bit module on a whim and same issue. I'm totally lost as to why it "fails to load" when you hit the website and shuts down the default app pool causing a 503. Is there any log that will tell me something more useful than "the data is in the error"? On 8/26/11 12:09 PM, "Yadin Flammer" wrote: Am I to gather that the main release 3.03 simply does not work in 2008 R2? I'm seeing there are significant configuration and behavioral differences in IIS from 2008, and when I try to make things match up they invariably revert themselves. The DefaultAppPool for example is set to Classic and ApplicationPoolIdentity instead of Integrated and NetworkService like in 2008. Trying to change those only sticks for a short while, then it reverts itself back. I've also at one person's recommendation tried to disable 32bit applications in the pool, but invariably that re-enables itself as well. This does of course lead me to question if there are huge bugs in IIS in R2, or if there are other forces at work reverting these that I'm not aware of. I also find that having the key under the section added to the applicationHost.config causes the 503 to go away because it causes the module to become unregistered and therefore not used. If I have this line in place but leave it as the example instead of setting it for our location, then it doesn't unload the module, but the app pool shutdown and 503 issue continues. So yea... Any other ideas or do I need to just move to the beta 3.1 because it's more stable than the release 3.03? The rapid fail doesn't do anything unfortunately, other than make the failure take longer and fill the event viewer. Thanks, Yadin On 8/26/11 9:31 AM, "Stucky, David" wrote: Yadin, Sounds like you are having the same issues on Win 2008 R2 that we were seeing. One temporary quick fix is to increase the specific Application Pool's Rapid-Fail Protection settings under Advanced Settings. We ended up with 100 Maximum Failures in a 5min Failure Interval. You could just disable Rapid-Fail, but that would be a bad idea. The better long term fix is to get your hands on Cosign Module 3.1.0 RC2. This release candidate has seemed to fixed our problems with Cosign crashing the IIS 7.5 application pool. It is my understanding that an official updated production release is coming. Thanks... David Stucky, CISSP, GSEC Systems Security Analyst Office of Human Resources Information Systems 503 James M. Elliott Building 814-865-4049 d...@psu.edu From: Yadin Flammer [mailto:y...@psu.edu] Sent: Thursday, August 25, 2011 6:47 PM To: cosign-discuss@lists.sourceforge.net Subject: [Cosign-discuss] 503 and stopped app pool I'm at a loss what is happening as I set this server up in the same method as another that works fine. The only difference is this is 2008 R2 and the other is 2008, so 64bit vs 32bit. When I hit the site, it eventually spits back a 503. I then go to IIS and find the defaultapppool is stopped. The event log says cosignmodule.dll failed to load the data is in the error, whatever that is supposed to mean. I'm trying to figure out why the module is failing to load and causing the apppool to die. The system log mentions it reported a listener channel failure, again whatever that means. Any thoughts where I can get more detail what is failing? Thanks, Yadin
Re: [Cosign-discuss] 503 and stopped app pool
On 08/25/2011 06:46 PM, Yadin Flammer wrote: I'm at a loss what is happening as I set this server up in the same method as another that works fine. The only difference is this is 2008 R2 and the other is 2008, so 64bit vs 32bit. For the troubled server, what's the bit-ness of: Windows/IIS, App Pools? -Phil -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
