Windows Auto Suite/Running As Service Questions

We installed the Windows automation Suite on Win 2003 Server and have our license on this server. We plan to use the GUI to schedule and edit jobs in the jobs database on this machine only.

We now want to run the scheduler as a service on the same machine so one of us does not need to be logged into the machine at all times with our user id and the GUI running all the time. I understand we need to set it to run as a service by setting the options - that seems fairly straight forward. we also understand we need to have access to our network, so we will use a user id and password associated with the service that will allow us access to network resources.

1. Are we required to reboot in order for the service to run (we would rather not reboot since this is a highly available machine that needs to stay up as mush as possible)? It would seem the service would start and run just fine without rebooting. I understand we need to start it the first time after checking the checkbox that we are running as a service.

2. What is the proper way to edit jobs and and schedules while running the service on the same machine as where the GUI is installed? In other words, what is the protocol for making schedule changes while running in service mode? We have one license.
3. Are there any other caveats we should be aware of when running in this mode ...

Thanks.

Hi,

Here are answers for your questions

	Quote:
	1. Are we required to reboot in order for the service to run (we would rather not reboot since this is a highly available machine that needs to stay up as mush as possible)? It would seem the service would start and run just fine without rebooting. I understand we need to start it the first time after checking the checkbox that we are running as a service.

No, you don't need to reboot the server. After you install the service you can start it manually from the Services applet in the Control Panel

	Quote:
	2. What is the proper way to edit jobs and and schedules while running the service on the same machine as where the GUI is installed? In other words, what is the protocol for making schedule changes while running in service mode? We have one license.

Method 1: Use 24x7 Remote Control to work with the scheduler in the client-server mode and edit jobs remotely. You don't even need to be on the server, you can do it directly from your workstation. Note, for every 24x7 installation you need a separate license

Method 2: Use 24x7 web-based interface, similar to the remote control but web based and requires only a web browser. This option requires a site license or licensing the web-console separately.

Method 3. Upgrade to 24x7 Multi-platform Edition v4. In this version in addition to methods 1 and 2 you can also use command-line based console to edit jobs directly on the server.

All 3 described methods support multiple concurrent users.

	Quote:
	3. Are there any other caveats we should be aware of when running in this mode ...

Sure, Windows services have certain limitations for network access, desktop access, security settings. Any application/job started from a service inherits these limitations. For example, if in your jobs you refer to network files using drive mapping, you would need to replace such references with UNC file path. Other changes might be needed to accommodate specifics of Windows service design.

I see your 3 options, but each one of them involves us buying another license and not using the Windows GUI already on the 2003 machine. Are you saying that we cannot edit the schedules using the Windows GUI on that machine, knowing that the timer will suspend while we are doing the edits, and then resume after we close the Windows GUI?

No. Of course you can use this method. Just understand the consequences of using this method. The GUI in this mode is not a console connected to the scheduler service. Every time you make it save the changes, the GUI restarts the service automatically (if the service is running, so it can pickup the latest changes). Any jobs running at that time can be affected, and in the worst case aborted completely. You don't really know what is running as you cannot see it on the screen, the GUI is not connected.

You can of course, stop the service first, start the GUI, make changes (let's say it takes 15 minutes or 30 minutes to change and test new stuff) and then restart the service.

PS. My 2 cents personal opinion is that the cost of the 24x7 license now is sooo low that unless you are only going to have several jobs scheduled and running infrequently, it is just not worse to use the procedure described above and deal with the service downtimes, not to mention that you have to be at the server to use it.

Thanks, this is the clarification that I needed.