I can not connect to ServerA running 24x7 in distributed mode from PCA running 24x7 remote control
I can connect to ServerB running 24x7 in distributed mode from a PCA running 24x7 remote control...
So I believe the 24x7 remote control on PCA is working fine
I can connect to ServerA with remote controls from other PCs, PCB & PCC...
so I believe the server side is working fine

So briefly,
PCA can't connect to ServerA, but it can connect ServerB
PCB, PCC can connect to ServerA and ServerB

On PCA, (that can not connect) receives this info in the trace while trying to connect to ServerA

DPB01 Connection(04B10688): ConnectToServer : application(1096), location(ip.add.serverA), driver(WinSock). ... (00000000)
SMI02 Connection(04B10808): ERROR OCCURRED: The server '1096' could not be located. It is probably not started. (00000002)
DPB01 Connection(04B10688): ConnectToServer : application(1096), location(ip.add.serverA), driver(WinSock). FAILED (80042005

Can this help determine the problem?
I tried removing the app from PCA and reinstalling it, still can't connect
Is there something I can remove from the registry that will ensure I am removing all of this app?

I think this might have something to do with licensing
When we first tried this product, it was installed on PCA
Later the app was moved to ServerA, and uninstalled on PCA
We have just bought 6 more licences to put 24x7 on varius devices including PCA
This failure to connect seems very similar to the problem I had earlier when I was trying to test the distributed environment with all the devices running trial version of 24x7.
SysOp stated the reason these systems could not connect to each other was because the need different licenses.
Maybe PCA still has some reminisce of the old license?

Please check first what you get on ServerA in the log file (schedule.log). Are there any errors like "connection refused?" Also make sure ServerA and PCA don't use the same license key.

: I can not connect to ServerA running 24x7 in distributed mode from PCA
: running 24x7 remote control
: I can connect to ServerB running 24x7 in distributed mode from a PCA running
: 24x7 remote control...
: So I believe the 24x7 remote control on PCA is working fine
: I can connect to ServerA with remote controls from other PCs, PCB &
: PCC...
: so I believe the server side is working fine

: So briefly,
: PCA can't connect to ServerA, but it can connect ServerB
: PCB, PCC can connect to ServerA and ServerB

: On PCA, (that can not connect) receives this info in the trace while trying
: to connect to ServerA

: DPB01 Connection(04B10688): ConnectToServer : application(1096),
: location(ip.add.serverA), driver(WinSock). ... (00000000)
: SMI02 Connection(04B10808): ERROR OCCURRED: The server '1096' could not be
: located. It is probably not started. (00000002)
: DPB01 Connection(04B10688): ConnectToServer : application(1096),
: location(ip.add.serverA), driver(WinSock). FAILED (80042005

: Can this help determine the problem?
: I tried removing the app from PCA and reinstalling it, still can't connect
: Is there something I can remove from the registry that will ensure I am
: removing all of this app?

: I think this might have something to do with licensing
: When we first tried this product, it was installed on PCA
: Later the app was moved to ServerA, and uninstalled on PCA
: We have just bought 6 more licences to put 24x7 on varius devices including
: PCA
: This failure to connect seems very similar to the problem I had earlier when
: I was trying to test the distributed environment with all the devices
: running trial version of 24x7.
: SysOp stated the reason these systems could not connect to each other was
: because the need different licenses.
: Maybe PCA still has some reminisce of the old license?

: Please check first what you get on ServerA in the log file (schedule.log).
: Are there any errors like "connection refused?" Also make sure
: ServerA and PCA don't use the same license key.

I stopped the service on ServerA
I cleared the log file
Started service on ServerA
Tried to connect with PCA, tried multiple times
This is what the log had, (basicaly nothing about the attempt to connect)
10/27/2005 17:10:52 0 0 0 24x7 Scheduler [24x7 service] 24x7 Scheduler starting...

SNs are different
SN for ServerA = XXXXX-XXXXXXX-XXX39
SN for PCA = XXXXX-XXXXXXX-XXX96

btw I have noticed a problem connecting to serverA from PCB and PCC
PCB and PCC can only access the .dat files if they are on ServerA
If I open test1.dat file on ServerA, everything works fine controlling jobs from PCA or PCB
If I open test2.dat file from a newtork share (mapped drive) then when I access the examples jobs.dat, not the last open db, test2.dat
Is this correct? I would like the .dat files to be on a netowrk share.

procedure used for changing db
stop service on ServerA
open 24x7 on ServerA
open .dat file
make a change to a job (like the name of the job something easy to reconize)
save .dat file
close 24x7
start service
connect from PCB
make sure change is visable
make another change
close connection
connect from PCC
make sure change is visable
close connection

Just a guess. When you select a file on a network share you use File/Open menu in 24x7 and browse to the share using share mapping name. Then you start the service and it does not work. The reason for that is services cannot use file mappings, they simply do not see them). The file name must be entered in UNC file format as \\server\share\folder\file.dat.

Try that after the next suggestion.

Before you attempt to connect to a service on ServerA try running 24x7 in non-service mode (as an application) and connecting to it from PCA, PCB and PCC. If you can do that, run 24x7 on ServerA and try connecting again. If the service is properly setup and uses local or UNC name for the file you should be able to connect to it just like before when it was run as an application.

: I stopped the service on ServerA
: I cleared the log file
: Started service on ServerA
: Tried to connect with PCA, tried multiple times
: This is what the log had, (basicaly nothing about the attempt to connect)
: 10/27/2005 17:10:52 0 0 0 24x7 Scheduler [24x7 service] 24x7 Scheduler
: starting...

: SNs are different
: SN for ServerA = XXXXX-XXXXXXX-XXX39
: SN for PCA = XXXXX-XXXXXXX-XXX96

: btw I have noticed a problem connecting to serverA from PCB and PCC
: PCB and PCC can only access the .dat files if they are on ServerA
: If I open test1.dat file on ServerA, everything works fine controlling jobs
: from PCA or PCB
: If I open test2.dat file from a newtork share (mapped drive) then when I
: access the examples jobs.dat, not the last open db, test2.dat
: Is this correct? I would like the .dat files to be on a netowrk share.

: procedure used for changing db
: stop service on ServerA
: open 24x7 on ServerA
: open .dat file
: make a change to a job (like the name of the job something easy to reconize)
: save .dat file
: close 24x7
: start service
: connect from PCB
: make sure change is visable
: make another change
: close connection
: connect from PCC
: make sure change is visable
: close connection

: Just a guess. When you select a file on a network share you use File/Open
: menu in 24x7 and browse to the share using share mapping name. Then you
: start the service and it does not work. The reason for that is services
: cannot use file mappings, they simply do not see them). The file name must
: be entered in UNC file format as \\server\share\folder\file.dat.

: Try that after the next suggestion.

: Before you attempt to connect to a service on ServerA try running 24x7 in
: non-service mode (as an application) and connecting to it from PCA, PCB
: and PCC. If you can do that, run 24x7 on ServerA and try connecting again.
: If the service is properly setup and uses local or UNC name for the file
: you should be able to connect to it just like before when it was run as an
: application.

Ok, the UNC took care of the new problem, so I can not connect to serverA if its pointing to an UNC path, however
PCA still cannot connect to ServerA in either App or service mode
PCA does not have a firewall running
PCB and PCC can connect fine to ServerA as an app or service
So I beleive the Server side is running fine

I tried removing the app from PCA and reinstalling it, still can't connect
Is there something I can remove from the registry that will ensure I am removing all of this app?

Just a guess. When you select a file on a network share you use File/Open menu in 24x7 and browse to the share using share mapping name. Then you start the service and it does not work. The reason for that is services cannot use file mappings, they simply do not see them). The file name must be entered in UNC file format as \\server\share\folder\file.dat.

Try that after the next suggestion.

Before you attempt to connect to a service on ServerA try running 24x7 in non-service mode (as an application) and connecting to it from PCA, PCB and PCC. If you can do that, run 24x7 on ServerA and try connecting again. If the service is properly setup and uses local or UNC name for the file you should be able to connect to it just like before when it was run as an application.

: I stopped the service on ServerA
: I cleared the log file
: Started service on ServerA
: Tried to connect with PCA, tried multiple times
: This is what the log had, (basicaly nothing about the attempt to connect)
: 10/27/2005 17:10:52 0 0 0 24x7 Scheduler [24x7 service] 24x7 Scheduler
: starting...

: SNs are different
: SN for ServerA = XXXXX-XXXXXXX-XXX39
: SN for PCA = XXXXX-XXXXXXX-XXX96

: btw I have noticed a problem connecting to serverA from PCB and PCC
: PCB and PCC can only access the .dat files if they are on ServerA
: If I open test1.dat file on ServerA, everything works fine controlling jobs
: from PCA or PCB
: If I open test2.dat file from a newtork share (mapped drive) then when I
: access the examples jobs.dat, not the last open db, test2.dat
: Is this correct? I would like the .dat files to be on a netowrk share.

: procedure used for changing db
: stop service on ServerA
: open 24x7 on ServerA
: open .dat file
: make a change to a job (like the name of the job something easy to reconize)
: save .dat file
: close 24x7
: start service
: connect from PCB
: make sure change is visable
: make another change
: close connection
: connect from PCC
: make sure change is visable
: close connection

UNC and connecting to server are different unrelated things. UNC was mentioned to ensure you have the 24x7 service starting and able to find the job database file. As long as you can connect from one machine, you should be able to connect from another machine.

Please ty pinging ServerA from PCA using the name or IP address entered in the remote host properties. If you can do, next enable tracing on both PCA in host profile settings and on ServerA in Tools/Options/Network, and try the connection. If it fails, send both trace files (master.log from server; rcontrol.log from PC) along with schedule.log file from both machines to support@softtreetech.com for further analysis.

: Ok, the UNC took care of the new problem, so I can not connect to serverA if
: its pointing to an UNC path, however
: PCA still cannot connect to ServerA in either App or service mode
: PCA does not have a firewall running
: PCB and PCC can connect fine to ServerA as an app or service
: So I beleive the Server side is running fine

: I tried removing the app from PCA and reinstalling it, still can't connect
: Is there something I can remove from the registry that will ensure I am
: removing all of this app?

: Just a guess. When you select a file on a network share you use File/Open
: menu in 24x7 and browse to the share using share mapping name. Then you
: start the service and it does not work. The reason for that is services
: cannot use file mappings, they simply do not see them). The file name must
: be entered in UNC file format as \\server\share\folder\file.dat.

: Try that after the next suggestion.

: Before you attempt to connect to a service on ServerA try running 24x7 in
: non-service mode (as an application) and connecting to it from PCA, PCB
: and PCC. If you can do that, run 24x7 on ServerA and try connecting again.
: If the service is properly setup and uses local or UNC name for the file
: you should be able to connect to it just like before when it was run as an
: application.