DSM Agents fail to deploy over Checkpoint VPN
I am trying to deploy CA DSM R11.2 over a Checkpoint VPN. Network wise, everything seems OK. The package downloads and begins to install, but then fails.
The logs seem to imply that the VPN access point is trying to emulate the Domain Manager and the package fails to "Access the Application." Even CA Tech support is confused by this.
Does anyone have any experience why packages would fail over a VPN that is otherwise working fine, or specifically, why CA DSM packages would fail?
Also, if I manually install the package, some of the features of the software don't work, but others do.
Many thanks for any insight or thoughts.
The logs seem to imply that the VPN access point is trying to emulate the Domain Manager and the package fails to "Access the Application." Even CA Tech support is confused by this.
Does anyone have any experience why packages would fail over a VPN that is otherwise working fine, or specifically, why CA DSM packages would fail?
Also, if I manually install the package, some of the features of the software don't work, but others do.
Many thanks for any insight or thoughts.
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
jbhammon
14 years ago
The logs are exhausting. Dozens of log files. . . . that don't really tell anything.
The only things of real interest is the CAMSTAT command. (Posted below in abridged form)
The hosts on a normal deployment always include the domain manager. Howerver, on VPN clients, the hosts include 1,2, and sometimes all 3 of the companies public DNS servers ip addresses and never the domain manager. It's as if the DNS servers are trying to translate, emulate, or are otherwise getting confused for the domain manager. The CAM.EXE service continues to try and install the software, but continues to restart because it "cannot access the application."
If we manually put the IP Address in the cam.cfg file and pre-install it, or prelocate it before the install, the install works fine.
We are looking at different options for deploying the modified cam.cfg file, but I'm hoping that someone else has seen this sort of thing before and has a suggestion that might help without modifing the package.
thanks
C:\>camstat
CAM - uspakenitod0007.xxxxxxxx.com Version 1.11 (Build 54_16) up 43 days 4:26
Host proto state port Qlen m/sent m/recv retry disc RTO
--------------------- ----- ----- ----- ----- ------- ------- ------ ----- ----
xx.10.0.6 udp --- 4104 0 2 0 0 0 1
xx.26.0.9 udp --- 4104 0 0 1 4 62 1
Application proto state port Qlen m/sent m/recv retry disc hold
--------------- ----- ----- ----- ----- ------- ------- ------ ----- ----
CAI025872-00000 tcp CON 4105 7 0 1 0 0 60
...........about 50 simaliar lines.
Hosts 6 - 1 cots (1 active), 5 udp, total queued 0, ave qlen 0.0
Applications 59 (58 active), total queued 11, ave qlen 0.2
Load average (m/s): send 0.50, 1.42, 0.75, receive 0.50, 1.42, 0.75
Total messages: sent 2785782, received 2793519
Supported Protocols: UDP, TCP, CAS
C:\>
The only things of real interest is the CAMSTAT command. (Posted below in abridged form)
The hosts on a normal deployment always include the domain manager. Howerver, on VPN clients, the hosts include 1,2, and sometimes all 3 of the companies public DNS servers ip addresses and never the domain manager. It's as if the DNS servers are trying to translate, emulate, or are otherwise getting confused for the domain manager. The CAM.EXE service continues to try and install the software, but continues to restart because it "cannot access the application."
If we manually put the IP Address in the cam.cfg file and pre-install it, or prelocate it before the install, the install works fine.
We are looking at different options for deploying the modified cam.cfg file, but I'm hoping that someone else has seen this sort of thing before and has a suggestion that might help without modifing the package.
thanks
C:\>camstat
CAM - uspakenitod0007.xxxxxxxx.com Version 1.11 (Build 54_16) up 43 days 4:26
Host proto state port Qlen m/sent m/recv retry disc RTO
--------------------- ----- ----- ----- ----- ------- ------- ------ ----- ----
xx.10.0.6 udp --- 4104 0 2 0 0 0 1
xx.26.0.9 udp --- 4104 0 0 1 4 62 1
Application proto state port Qlen m/sent m/recv retry disc hold
--------------- ----- ----- ----- ----- ------- ------- ------ ----- ----
CAI025872-00000 tcp CON 4105 7 0 1 0 0 60
...........about 50 simaliar lines.
Hosts 6 - 1 cots (1 active), 5 udp, total queued 0, ave qlen 0.0
Applications 59 (58 active), total queued 11, ave qlen 0.2
Load average (m/s): send 0.50, 1.42, 0.75, receive 0.50, 1.42, 0.75
Total messages: sent 2785782, received 2793519
Supported Protocols: UDP, TCP, CAS
C:\>
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.