Isolated Testing Environment

Hi,

Is it possible to configure a single instance of 24x7 on one workstation to act as a self contained testing environment acting as both the source and destination nodes for network operations and scheduling/remote control activities ?

Jim

If the scheduler is setup to run as a server then it can run both local jobs and remote jobs (it can send jobs to other schedulers and agents) as well as it can accept and run remote jobs submitted by other schedulers and agents. In this situation you can.

To enable the server mode use Tools/Options menu, click the Network page and then check "distributed server mode" option.

: Hi,

: Is it possible to configure a single instance of 24x7 on one workstation to
: act as a self contained testing environment acting as both the source and
: destination nodes for network operations and scheduling/remote control
: activities ?

: Jim

O.K. but just to clarify for me - does this mean that on an NT4 Workstation I can install
the 24x7 Automation Suite and provided I configure the
24x7 Scheduler NOT to run as an NT service and enable the
Distributed server mode option, then I can create jobs/queues etc. on the workstation using
the scheduler interface and ALSO run jobs via the remote agent I will define for the same workstation ?

Thanks,

Jim

: If the scheduler is setup to run as a server then it can run both local jobs
: and remote jobs (it can send jobs to other schedulers and agents) as well
: as it can accept and run remote jobs submitted by other schedulers and
: agents. In this situation you can.

: To enable the server mode use Tools/Options menu, click the Network page and
: then check "distributed server mode" option.

Server mode has nothing to do with jobs or queues. You can run queues and job regardless of the state of the server mode. When enabled this option simply activities network listener and server part.

You can install 24x7 on any Windows system (except Windows CE). Whether it is server or workstation, doesn't really matter. Windows NT 4.0 is also good.

You don't need to define separate agent for that workstation. The "server" option turns the agent part. In other words the agent is built-in.

Please see the "24x7 Scheduler Architecture" chart in the Overview topic in the on-line help. You will need to scroll couple of pages down when you open this topic. Also check out "About Remote Agents and Remote Jobs" topic. It may help you to understand better 24x7 internal parts.

: O.K. but just to clarify for me - does this mean that on an NT4 Workstation I
: can install
: the 24x7 Automation Suite and provided I configure the
: 24x7 Scheduler NOT to run as an NT service and enable the
: Distributed server mode option, then I can create jobs/queues etc. on the
: workstation using
: the scheduler interface and ALSO run jobs via the remote agent I will define
: for the same workstation ?

: Thanks,

: Jim

Hi,

I did check out the Architecture section and the reason I asked for clarification
is that when I set it up as described on my NT4 Workstation and I define an agent
on my workstation specifying the IP Address and try the "test connection" it goes
away and NEVER comes back. Hence I thought that I had a problem understanding.

Any further help appreciated,

Jim

: Server mode has nothing to do with jobs or queues. You can run queues and job
: regardless of the state of the server mode. When enabled this option
: simply activities network listener and server part.

: You can install 24x7 on any Windows system (except Windows CE). Whether it is
: server or workstation, doesn't really matter. Windows NT 4.0 is also good.

: You don't need to define separate agent for that workstation. The
: "server" option turns the agent part. In other words the agent
: is built-in.

: Please see the "24x7 Scheduler Architecture" chart in the Overview
: topic in the on-line help. You will need to scroll couple of pages down
: when you open this topic. Also check out "About Remote Agents and
: Remote Jobs" topic. It may help you to understand better 24x7
: internal parts.

Don't you get any errors on any side? Have you tried turning on the trace option (on both sides) to see call trace messages and possible errors?

Do you use the same port number? Make sure you don't run both 24x7 Scheduler (or Agent) as a service and at the same time 24x7 running interactive on the same server machine. This may confuse the connecting component and make it hang.

If all answers are positive, try pinging the NT4 machine from your workstation by name and see if you get the correct IP returned. Hanging problems during connections usually indicates problems with name or IP resolution

: Hi,

: I did check out the Architecture section and the reason I asked for
: clarification
: is that when I set it up as described on my NT4 Workstation and I define an
: agent
: on my workstation specifying the IP Address and try the "test
: connection" it goes
: away and NEVER comes back. Hence I thought that I had a problem
: understanding.

: Any further help appreciated,

: Jim

Aha !

From your response I see that I have not adequately described my proposed "testing environment"

I have one (and only one) NT4 workstation which would like to configure as supporting both
the 24x7 scheduler and acting as the remote agent. Hence I have installed 24x7 on the workstation
and from the 24x7 scheduler I add a remote agent and specify the IP address of the SAME workstation.
When I then try to test connection forthis agent it hangs.

Should it be possible to get this configuration to work ?

Thanks,

Jim

: Don't you get any errors on any side? Have you tried turning on the trace
: option (on both sides) to see call trace messages and possible errors?

: Do you use the same port number? Make sure you don't run both 24x7 Scheduler
: (or Agent) as a service and at the same time 24x7 running interactive on
: the same server machine. This may confuse the connecting component and
: make it hang.

: If all answers are positive, try pinging the NT4 machine from your
: workstation by name and see if you get the correct IP returned. Hanging
: problems during connections usually indicates problems with name or IP
: resolution

I see it now. No you cannot run both the scheduler and the agent on the same machine at the same time. But you could have a "loop-back thing" if you run detached jobs. Because detached jobs are ru nby a separate instance of 24x7 they can connect to the main instance running on the same machine.

I am not sure if this kind of loop-back setup is of any use in your situation. What do you gain by running jobs locally using "remote" connection instead of running them just locally? You can always test them locally and when deploying jobs to the production environment simply change the host property.

: Aha !

: From your response I see that I have not adequately described my proposed
: "testing environment"

: I have one (and only one) NT4 workstation which would like to configure as
: supporting both
: the 24x7 scheduler and acting as the remote agent. Hence I have installed
: 24x7 on the workstation
: and from the 24x7 scheduler I add a remote agent and specify the IP address
: of the SAME workstation.
: When I then try to test connection forthis agent it hangs.

: Should it be possible to get this configuration to work ?

: Thanks,

: Jim

It's just that the scripts I'm working on use SynchRemoteDir (for example) and I need to be able to use these command and specify the remote agennt etc.

Jim

: I see it now. No you cannot run both the scheduler and the agent on the same
: machine at the same time. But you could have a "loop-back thing"
: if you run detached jobs. Because detached jobs are ru nby a separate
: instance of 24x7 they can connect to the main instance running on the same
: machine.

: I am not sure if this kind of loop-back setup is of any use in your
: situation. What do you gain by running jobs locally using
: "remote" connection instead of running them just locally? You
: can always test them locally and when deploying jobs to the production
: environment simply change the host property.

Ok, I understand now what you are doing. To test such jobs you can run the scheduler in the server mode as we have discussed earlier. While the scheduler is running start 24x7 Remote Control on the same machine and connect to the local scheduler. This way you can also have 2 instances of 24x7 on the same computer. When running or debugging these jobs using 24x7 Remote Control and prompted whether you want to test run them locally or remotely always choose to run them locally. That's how you can test and debug SyncRemoteDir. You can also run them from DOS command line as "24x7 /JOB [job id]"

Using 2 computers may be still easier as you don't have to remember to run multiple things and you don't have to kill 24x7 from the Task Manager every time you forget to use the Remote Control or while in the Remote control forget to click the Local Run button in the end getting a hung job trying to connect to itself.

: It's just that the scripts I'm working on use SynchRemoteDir (for example)
: and I need to be able to use these command and specify the remote agennt
: etc.

: Jim

O.K. - the remote control option should be o.k. for me for while anyway.

If using the remote control option and running/debugging the test jobs loaclly
what should the SynchRemoteDir parameters for "master" and "agent" be and will they
need to be changed when the job is run for real on the server ?

Thanks,

Jim

: Ok, I understand now what you are doing. To test such jobs you can run the
: scheduler in the server mode as we have discussed earlier. While the
: scheduler is running start 24x7 Remote Control on the same machine and
: connect to the local scheduler. This way you can also have 2 instances of
: 24x7 on the same computer. When running or debugging these jobs using 24x7
: Remote Control and prompted whether you want to test run them locally or
: remotely always choose to run them locally. That's how you can test and
: debug SyncRemoteDir. You can also run them from DOS command line as
: "24x7 /JOB [job id]"

: Using 2 computers may be still easier as you don't have to remember to run
: multiple things and you don't have to kill 24x7 from the Task Manager
: every time you forget to use the Remote Control or while in the Remote
: control forget to click the Local Run button in the end getting a hung job
: trying to connect to itself.

If you use the same Agent Profile name in the configuration on the development computer and production server then you won't need to change the job after it is deployed to the production server. Using the same name does not mean that you use the same parameters for the profile.

For example, if on the server you used "Profile A" as reference name for one of the agents and you want to test this job locally on your workstation or test server, create new "Profile A" using Tools/Remote Agent Profiles menu. In the location property enter LocalHost or 127.0.0.1, in the port property enter whatever you adapted as a common number for your systems, for example 1096.

In the job script in SyncRemoteDir specify either "REMOTE" or "LOCAL" for the first parameter depending on the direction in which you want to send files (if sending from remote to local, specify "REMOTE", otherwise specify "LOCAL"). For the second Parameter specify "Profile A" as the remote agent name, specify values for the remaining parameters as required by the business logic.

Note: When the job runs locally on your workstation it will pull connection properties for Profile A as you entered them on your workstation. When deployed and run on the production server it will pull connection properties for Profile A as they are entered on the server.

: O.K. - the remote control option should be o.k. for me for while anyway.

: If using the remote control option and running/debugging the test jobs
: loaclly
: what should the SynchRemoteDir parameters for "master" and
: "agent" be and will they
: need to be changed when the job is run for real on the server ?

: Thanks,

: Jim

Many Thanks - hope fully this will be the last silly question on this thread for a while - so here goes :-

If I specify "REMOTE" and am sending directories/files from remote computer to local computer (which is hosting the scheduler)
when I specify the "Source_dir" parameter is the device/path naming "relative" to the remote computer ? By this I mean :-
If the files to be copied are on the x: drive under folder "DATA" (shared out as DATA_SHARE)on remote computer "REMOTE" do I specify "Source_dir"
as "x:\DATA" OR should it be "\\REMOTE\DATA_SHARE" ?

Thanks again,

Jim

: If you use the same Agent Profile name in the configuration on the
: development computer and production server then you won't need to change
: the job after it is deployed to the production server. Using the same name
: does not mean that you use the same parameters for the profile.

: For example, if on the server you used "Profile A" as reference
: name for one of the agents and you want to test this job locally on your
: workstation or test server, create new "Profile A" using
: Tools/Remote Agent Profiles menu. In the location property enter LocalHost
: or 127.0.0.1, in the port property enter whatever you adapted as a common
: number for your systems, for example 1096.

: In the job script in SyncRemoteDir specify either "REMOTE" or
: "LOCAL" for the first parameter depending on the direction in
: which you want to send files (if sending from remote to local, specify
: "REMOTE", otherwise specify "LOCAL"). For the second
: Parameter specify "Profile A" as the remote agent name, specify
: values for the remaining parameters as required by the business logic.

: Note: When the job runs locally on your workstation it will pull connection
: properties for Profile A as you entered them on your workstation. When
: deployed and run on the production server it will pull connection
: properties for Profile A as they are entered on the server.

There are no silly questions.
In theory both answers are correct. Yes the path should be specified as it is seen by the remote agent, but the UNC name should also work from anywhere. If you can access remote files using \\REMOTE\DATA_SHARE try experimenting with running SyncLocalDir instead of SyncRemoteDir. In many cases the performance could be much better.

Also, keep in mind that NT services cannot use drive mapping for file references, I mean that if the remote agent is run as a service it cannot use X: in path and file names.

: Many Thanks - hope fully this will be the last silly question on this thread
: for a while - so here goes :-

: If I specify "REMOTE" and am sending directories/files from remote
: computer to local computer (which is hosting the scheduler)
: when I specify the "Source_dir" parameter is the device/path naming
: "relative" to the remote computer ? By this I mean :-
: If the files to be copied are on the x: drive under folder "DATA"
: (shared out as DATA_SHARE)on remote computer "REMOTE" do I
: specify "Source_dir"
: as "x:\DATA" OR should it be "\\REMOTE\DATA_SHARE" ?

: Thanks again,

: Jim

I'm glad I asked now ;) as until I read your response I wasn't aware that the fact that I am running the 24x7 scheduler as a service on the remote machines
would prevent me using the drive mappings :(

Jim

: There are no silly questions.
: In theory both answers are correct. Yes the path should be specified as it is
: seen by the remote agent, but the UNC name should also work from anywhere.
: If you can access remote files using \\REMOTE\DATA_SHARE try experimenting
: with running SyncLocalDir instead of SyncRemoteDir. In many cases the
: performance could be much better.

: Also, keep in mind that NT services cannot use drive mapping for file
: references, I mean that if the remote agent is run as a service it cannot
: use X: in path and file names.