<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: CDT is NOT GA ready. in General Topics</title>
    <link>https://community.checkpoint.com/t5/General-Topics/CDT-is-NOT-GA-ready/m-p/95580#M18820</link>
    <description>&lt;P&gt;Hi,&lt;BR /&gt;I also experienced the post upgrade policy save on the gateway that failed but it continued to go further with the checkups/upgrade and after the upgrade was done the policy couldn't not be installed at all, nor from cli or smartconsole.&lt;/P&gt;&lt;P&gt;In the logs it was obvious that it said verification failed and still continued.&lt;BR /&gt;Had to do a clean install.&lt;/P&gt;</description>
    <pubDate>Sat, 29 Aug 2020 19:14:47 GMT</pubDate>
    <dc:creator>funkylicious</dc:creator>
    <dc:date>2020-08-29T19:14:47Z</dc:date>
    <item>
      <title>CDT is NOT GA ready.</title>
      <link>https://community.checkpoint.com/t5/General-Topics/CDT-is-NOT-GA-ready/m-p/95576#M18819</link>
      <description>&lt;P&gt;So its week 1 using the central deployment tool (CDT) to upgrade to R80.40&lt;/P&gt;&lt;P&gt;I have already found 2 large pitfalls&lt;/P&gt;&lt;P&gt;The tool requires all admins to be disconnected (nobody connected as read/write). Yea I already knew this&lt;/P&gt;&lt;P&gt;The inability to push IPS correctly (IPS remains disables after the upgrade).&lt;/P&gt;&lt;P&gt;so no big deal, just push IPS after the upgrade is complete, the problem is this could be several hours later depending on the scope&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;What else does CDT have instore for me ?&lt;/P&gt;&lt;P&gt;Any other pitfalls ?&lt;/P&gt;</description>
      <pubDate>Sat, 29 Aug 2020 15:48:26 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/CDT-is-NOT-GA-ready/m-p/95576#M18819</guid>
      <dc:creator>Rob_Napholz</dc:creator>
      <dc:date>2020-08-29T15:48:26Z</dc:date>
    </item>
    <item>
      <title>Re: CDT is NOT GA ready.</title>
      <link>https://community.checkpoint.com/t5/General-Topics/CDT-is-NOT-GA-ready/m-p/95580#M18820</link>
      <description>&lt;P&gt;Hi,&lt;BR /&gt;I also experienced the post upgrade policy save on the gateway that failed but it continued to go further with the checkups/upgrade and after the upgrade was done the policy couldn't not be installed at all, nor from cli or smartconsole.&lt;/P&gt;&lt;P&gt;In the logs it was obvious that it said verification failed and still continued.&lt;BR /&gt;Had to do a clean install.&lt;/P&gt;</description>
      <pubDate>Sat, 29 Aug 2020 19:14:47 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/CDT-is-NOT-GA-ready/m-p/95580#M18820</guid>
      <dc:creator>funkylicious</dc:creator>
      <dc:date>2020-08-29T19:14:47Z</dc:date>
    </item>
    <item>
      <title>Re: CDT is NOT GA ready.</title>
      <link>https://community.checkpoint.com/t5/General-Topics/CDT-is-NOT-GA-ready/m-p/100898#M19581</link>
      <description>&lt;P&gt;Sometimes, CDT will report that it could not verify that policy was installed and it will stop. When checking the gateway, policy is there and using CDT with -resume option will continue with deployment plan (for us, it usually means installing JHF). Sometimes, gateway ends up with Initial policy. In that case, pushing policy usually solves it (but not always). Log will sometimes show "/opt/CPsuite-R80.40/fw1/state/local/FW1/local.ifs: Too many levels of symbolic links", pushing policy from management solves that too.&lt;/P&gt;&lt;P&gt;When upgrading several gateways, if one/some fail, it means you have to wait for all of the others to finish before you can attempt resume. If your upgrade time window is short, that can be an issue and it may be required to continue with manual JHF install and/or upgrade of other cluster member.&lt;/P&gt;&lt;P&gt;There is -retry option which never worked for us (neither CDT 1.7 nor 1.8, did not try with 1.9).&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;[Expert@*********:0]# ./CentralDeploymentTool -retry -server=***.***.***.***
The Domain Management Server is incorrect.
Cannot find a running Central Deployment Tool process in Domain Management Server -server=***.***.***.***.
Make sure that Central Deployment Tool is still running and try again. Contact Check Point support if this problem persists.
[Expert@*********:0]# ps aux | grep Centra
admin     6064  0.0  0.0   2648   584 pts/6    S+   07:00   0:00 grep --color=auto Centra
admin    17268  0.0  0.0  53564 13096 pts/4    Sl+  06:09   0:01 ./CentralDeploymentTool -execute -candidates /home/admin/****.csv -deploymentplan /home/admin/&lt;/LI-CODE&gt;&lt;P&gt;I don't know if it matters, but CDT was started with nohup, could that be a reason that -retry fails?&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;mdsenv ***.***.***.***
nohup ./CentralDeploymentTool -execute -candidates=/home/admin/*******.csv -deploymentplan=/home/admin/***********.xml -filter=/home/admin/************.txt -server=***.***.***.***&lt;/LI-CODE&gt;&lt;P&gt;One important note/tip: if CDT fails and you decide to finish the upgrade of cluster manually, you have to check/fix HA version:&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;fw ctl get int fwha_version&lt;/LI-CODE&gt;&lt;P&gt;If you get 9999, you have to set it back to correct value for your CP version. Don't forget to change fwkern.conf as well (remove the line which setting fwha_version).&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;fw ctl setsync off                  ## stop the sync
cphaprob syncstat                   ## to confirm sync is off
fw ctl set int fwha_version 3421    ## use correct value for you version
fw ctl get int fwha_version         ## to check if change was executed
fw ctl setsync start                ## start the sync
cphaprob syncstat                   ## to confirm sync is on again&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 02 Nov 2020 13:29:50 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/CDT-is-NOT-GA-ready/m-p/100898#M19581</guid>
      <dc:creator>Srdjan_B</dc:creator>
      <dc:date>2020-11-02T13:29:50Z</dc:date>
    </item>
    <item>
      <title>Re: CDT is NOT GA ready.</title>
      <link>https://community.checkpoint.com/t5/General-Topics/CDT-is-NOT-GA-ready/m-p/101020#M19610</link>
      <description>&lt;P&gt;Hi Rob&lt;/P&gt;&lt;P&gt;&amp;nbsp; I'm the R&amp;amp;D team leader accountable for CDT&lt;/P&gt;&lt;P&gt;&amp;nbsp; Indeed the fact that admins should be disconnected is bothering but currently it's a limitation.&lt;/P&gt;&lt;P&gt;&amp;nbsp; Regarding the push IPS policy - do you mean that the Gateway didn't pull it and you had to push it from the management or that you failed to push it from the management?&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;Boaz&lt;/P&gt;</description>
      <pubDate>Tue, 03 Nov 2020 12:55:31 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/CDT-is-NOT-GA-ready/m-p/101020#M19610</guid>
      <dc:creator>Boaz_Orshav</dc:creator>
      <dc:date>2020-11-03T12:55:31Z</dc:date>
    </item>
  </channel>
</rss>

