The scenernio is as follows:

One must be on a workstation behind an ISA firewall. The workstation must open a pptp tunnel through the firewall to a location outside the NAT. In my case this was another ISA installation across the internet which would accept a pptp connection. Next open a terminal server session to a workstation behind the Second remote ISA server. From here open a pptp session back to the first ISA server. When the initial connection is ended RRAS dies on the first installation. The errors are:

The Microsoft ISA Server Control service terminated with service-specific error 278540.

The Microsoft Web Proxy service depends on the Microsoft ISA Server Control service which failed to start because of the following error:
The service has returned a service-specific error code.

The Microsoft Firewall service depends on the Microsoft ISA Server Control service which failed to start because of the following error:
The service has returned a service-specific error code.

The Microsoft ISA Server Control service terminated with service-specific error 278540.

There are more of the same but you get the picture, a service cascade failure off RRAS. Though the RRAS error isn't trapped.

And you are wondering how did I come across this? Am I some super hacker? No, I was trying to test my authentication path on the first installation and I needed a remote station to attach to the outside of the first ISA box to test the configuration. Fortunatly the authentication configuration worked. Unfortunatly, testing this killed ISA. Yikes!

John

This is one to file away in case anybody else ever tries the same thing.

Thanks!

Tom

I don't believe this to actually be a weakness of ISA but rather RRAS which ISA rides on. Another way I to criple RRAS PPTP services I have replicated is reverse Terminal Serve down the pipe back to initial box which created the tunnel. What is required here is to determine what ip addresses are being assigned by RRAS. The way I discovered this weakness was when I wound open a tunnel from home to work and terminal serve back home to my box there. Howver this weakness isn't 1 to 1 in cause and effect but over a couple hours will result in RRAS failure. Again this is a weakness of RRAS.

John

say hello to my little friend.

Event ID 7031
The Microsoft ISA Server Control service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 0 milliseconds: No action.

Then the whole box just crapped out till rras was restarted. And worst of all RRAS again fails to report it has hung itself. How hard would it be for them to write a function to check that rras is still working and if not restart it like the iis pooled process space. Is this what is in store for the .net product line? I can't believe the amount of bugs which made it into the gold code. I mean come on!

When did you say SP3 is coming out???

John

SP3 should be out around Christmas

Tom

------------------
Tom Shinder
http://www.isaserver.org/shinder/

net stop remoteaccess
net start remoteaccess

put it in a .bat and chain this to isa control service failure.

Took me a bit to find the correct commands, on a dutch website (only thing I understood wa the commands). Now whenever isa pukes the rras service will be restarted. You gotta love it.

John

Thanks,

John

Try this:

net stop isactrl

This will stop the Scheduled download service, the Web Proxy Service, RRAS and the Firewall Service.

Tom

------------------
Tom Shinder
http://www.isaserver.org/shinder/

net stop fwsrv
net stop w3proxy
net stop w3schdwn
net stop remoteaccess
net stop isactrl
net start remoteaccess
net start isactrl
net start fwsrv
net start w3proxy
net start w3schdwn

John

Excellent! Thanks for doing the footwork on this.

Tom

------------------
Tom Shinder
http://www.isaserver.org/shinder/

In order to provide for a likely recovery of isa in the event the control service bail I have attempted to create a script to execute upon the control service failure.

First I included the above commands in a file called rrasrestart.bat. When the service failed the event log would say it was taking action to call the file, however the file was never called. So I took a look around ms and found an q article saying that what needed to be done (by design no less) is to preface the bat file with forcedos.exe and complete path to .bat. So I put this in the recover box so it read as follows.

forcedos.exe d:\rrasrestart.bat

The result of this was that the file could not be found by the system according to the event log. However if this exact line is executed from the run window it is happy.

So after a little while I figured maybe the system couldn't find the forcedos.exe so I located the forcedos.exe, went to the run window and typed.

c:\winnt\sytem32\foredos.exe d:\rrasrestart.bat.

It worked just fine from the command line.

So I added the above to the recovery field.

After I inserted the fault the event log tells me the syntax isn't correct.

What is the deal? I'm confused and little regretful this is how I spent my Sunday.

Any ideas? Anyone ever gotten this functionality to work?

Thanks,

John