I am running AyaNova on a W2K3 Server (Standard Ed.) with SP1. I have installed and configured ARAS-including setting it to run as a service–and can access it from remote clients. The problem is that although the service is running, I must be logged on at the server console. In effect, it appears that it runs as a service only if I am logged on to the console. As soon as I log off, the service must stop because I can’t access ARAS anymore.
Also, as a side issue, my backup process is missing the scdata.sc file (and one other, I can’t recall exactly which) while ARAS is running. From the documentation, it appeared that the files should be backed up unless someone was actually accessing the file (via ARAS) at the time the backup was running. I’m pretty sure this was not the case. So, I am faced with a dilemma…shutdown ARAS when I leave for the night so it gets backed up, or not getting the file backed up during my nightly tape backup.
What is the file date of AyaService.exe located in C:\Program Files\AyaNova on this 2003 computer?
Regarding backup of SCDATA.SC while ARAS is running:
While ARAS is running, a simple share is occurring when no users are actually accessing.
Your backup software may not allow even this.
If that is the case, a suggestion is to create a batch file that copies the SCDATA.SC file to another location prior to the backup so that it can be backed up on a regular basis without having to shut down ARAS
OK, I implemented the steps above, but still have the same problem. As long as I am logged on at the server console, I can access ARAS perfectly. As soon as I log off, I get “<SPAN id=errorText>The page cannot be displayed”.</SPAN>
The previous ARAS log files you sent prior to updating the AyaService.exe:
The ARAS.log from the root of the D:\ is from when ARAS is started as a desktop service (via the ARAS icon on the desktop, or via ARAS if in Startup)
The ARAS.log from the root of C:\ is from when ARAS is started as a service.
Now, both logs show starting and stopping on same days, but it was indicated that you run ARAS as a service.
I would like to see the actual flow of what is occurring, and we will go from there:
Confirm that the file version of Ayaservice.exe was and is 6/16/2005 that you used when you performed the service uninstallation, and reinstallation
2.Ensure any ARAS service is shut down, and ensure any ARAS desktop is shut down
Rename both ARAS.log files in C:\ and in D:\ to ARAS.log.BAK
Reboot the ARAS computer so it is at the log in prompt and has a chance to load all its services - do not log in
Without logging in on the ARAS computer, from another computer on the network confirm if can bring up the ARAS login web page
Now log in at the ARAS computer
From the same other computer, confirm if can bring up the ARAS log in page
Find the ARAS.log file that would have been newly created. Attach a copy of this file to your reply and indicate from which drive and path it was in. If there is an ARAS.log on both locations, rename one and attach both indicating location.
Now log out of the ARAS computer
From that same other computer, confirm if can bring up the ARAS log in page
Log back in to the ARAS computer, and attach a new copy of the ARAS.log file
Could you also confirm these steps were taken when the ARAS service was uninstalled, and than reinstalled - the reason is that if not done, than it would still have been using the old AyaService.exe settings from when you initially setup ARAS as a service class=cite cite="" type=“cite”>
Perform the un-installation of the ARAS service from the cmd prompt AyaService -u
Confirm that ARAS is not listed in Services (this indicates it has been removed from registry as well as registry settings)
Extract the attached to overwrite the existing AyaService.exe file in C:\Program Files\AyaNova
Perform the service installation at the cmd prompt using the 6/16/2005 versionfileAyaService -i
Confirm the AyaService.ini file has correct command line for location of database, etc
Start the service manually
Confirm can access ARAS log in page
Reboot the ARAS computer, and confirm accessibility whether logged in or not (of course once computer has had a chance to reload the service)