At 12:11 PM 4/4/97 -0600, you wrote:
>Um, this is in response to your RadiusNT Service start problems. Dale is
>correct, if you are running radius as a service(bg), then you MUST stop it
>before running a command line. If your radiusnt services was running in
>the bg before, then you obviously have done something to affect it. Here
>are some ideas:
So, it sounds like our indication that the RadiusNT service *has*
autostarted on boot may be false, since we can at the same time run radius
from a command prompt?
I can also type 'net stop radius' (service stopped), then 'net start radius'
(service started), and then *still* run it from a command prompt. I think
your Idea #4 below is sounding like the right one...
> 1.) If your server is set on a domain, then you SHOULD specify a user for
>radius to use when starting(i.e. so radiusnt can logon to the domain) If
>you do not, radiusnt will not start unless using a system account(not
>recommended), and generally does not put an event in the event
>log(depending on your audits). Create a user for RadiusNT ONLY, with very
>minimal restrictions to the domain, but this is dependent upon your global
Hmmm, will give this a try. Running only as a service in the past, we
haven't been concerned with actually starting RadiusNT at a prompt and with
> 2.) If you are running a PDC, and you recently replaced the PDC, make sure
>you go through all of your accounts and shares. This seems to be a bug
>with MS unless you carry two BDC's. Also check your Local Profiles :)
Will check all accounts and shares. We're running a PDC and one BDC, but
haven't recently replaced either.
> 3.) If the server is NOT on the domain, then you need to check your User
>Manager for an account for radiusnt to use. It is suggested(by MS) that
>you do not use a system account, but specify an account, much like you
>would for a domained server.
> 4.) If you updated to a newer version of RadiusNT, REMOVE the service from
>the command line and INSTALL the service using the new radius.exe. I have
>had a couple problems with NT SRV Security not wanting to allow version
>changes on the services.
>Hope this helps man! If you have any more questions, I will try and answer :)
Thanks Mitch, I think your #4 might be the answer, hadn't thought of that.
We recently upgraded from 1.16.NT (1/6/95) all the way to 1.16.60.
Everything else is running as it has been for over 18 months, but there have
no doubt been lots of changes. I'll post our results.
Thanks again for the help...