IGA 14.4 OVA platform & upgrade path

[William Cheang]

Hi Team,
As i understand from the IGA 14.4 release note. There are 2 flavors of VAPP, but in IGA download page, I only found 1 OVA file(which is the platform v2). 
Q1. Can't find the "Platform v1" ova file, any idea ? 
Q2. Is there a direct upgrade path for EXISTING 14.3 VAPP customer ?





regards,
William

[Joffrey Lemoigne]

Hi William,

 

Platform v1 is a patch that can be used to upgrade existing vApp 14.2/14.3 running on CentOS 6

Platform v2 is an ova to deploy fresh vApp 14.4 running on CentOS 8

 

Applying the 14.4 patch is a direct migration path however it should be only a temporary situation (step 1 of the Gradual Migration method) because the vApp will still run on CentOS 6 (EOL on Nov 2020) and 14.4 should run on CentOS 8

 

Please look at https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/identity-suite/14-4/virtual-appliance/Migrating-Virtual-Appliance.html

that explains the 2 ways (Gradual Migration or Side-by-Side Migration) to migrate existing vApp deployement. If you follow the steps for the Gradual Migration path, you will see a link to download the patch (https://support.broadcom.com/download-center/solution-detail.html?aparNo=SS16343&os=LINUX )

 

Hope that helps,

Joffrey.

This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

[William Cheang]

Hi Joffrey,
Regarding side-by-side migration, when i setup the new cluster with 14.4, it have to point the existing 14.3 database ?
Would it have impact on existing VAPP 14.3 that is connecting to 14.3 database ?


regards,
William

[Joffrey Lemoigne]

Hi William,

 

No, with side by side migration, your new 14.4 environment must use a different database.

By doing so, your 14.3 env is not impacted while you are setting up the 14.4 one

The data from 14.3 are migrated to 14.4 using Migration Xpress tool

 

Thanks,

Joffrey.

This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

[William Cheang]

Ok, it will be separate DB.

In my situation, i have 3 x VAPP(14.3) on PROD env and 3 VAPP(14.3) x in DR env,
so i shall upgrade node by node( 1 by 1)  ?

regards,
William

[Joffrey Lemoigne]

You have to decide 1st which migration path you plan to do.  As discussed, the separate/new DB is for side by side migration and in such a case, there is no need to upgrade your existing 14.3 env/nodes because the new 14.4 env is a separate one. You have to upgrade your existing 14.3 env only if you plan to do a gradual migration in such a case, it's the same DB as you have to apply 1st the 14.4 patch on the existing nodes running CentOS 6, then add new 14.4 nodes using the ova (CentOS 8) and then remove the CentOS 6 boxes from the cluster

This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

[Joffrey Lemoigne]

Hi William,

 

I've got additional information regarding side-by-side migration from our Engineering and the use of the existing 14.3 DB.

 

During the installation of the 14.4, pointing to the existing 14.3 DB will work and the DB will be upgraded to 14.4. However, your 14.3 environment should not be used after, while you still need to migrate other data via Migration Xpress tool before having your 14.4 up and running.

 

In order not to alter the 14.3 env, the other solution is to replicate the existing DB and use this new one during 14.4 installation. Only the activities performed in 14.3 (if any) after mirroring the DB would be lost in 14.4.

 

The gradual migration is still the recommended solution to avoid data loss in this case

 

Thanks,

Joffrey.

 

[William Cheang]

Hi Joffrey,
We plan todo the migration with these steps.

1. We will perform in-place upgrade from 14.3 to 14.4 on our existing VAPP(all 3 nodes)
2. We will mirror the in-place's upgraded 14.4 DB to another DB("Mirrored DB").
3. We will perform ldif backup on Userstore & Provisioning Store on this upgraded 14.4 VAPP.
3.1 We will backup the CA IM XML with Provisioning Role, Account Template info.

4. We will setup new VAPP with 14.4(Stream 8) with all 3 nodes, where it will point to mirrored 14.4 DB.
5. We will restore the ldif backup on Userstore & Provisioning store.
6. We will restore the CA IM XML Provisioing Role & Account Template info.

Will this works ?

regards,
William

[Joffrey Lemoigne]

Hi William,

 

It should work, yes. I don't believe the steps 3.1 & 6 are needed though as your DB in the new env will be already with your data as per step 4.

It could be faster to mirror the 14.3 DB, set up the new vApp Stream 8 based env pointing to this 14.3 "mirrored" DB and then use Migration Xpress to migrate userstore and prov store data.

Anyway, your tests should tell you what is your preferred way and if there is any missing steps.

 

Thanks,

Joffrey.

 

[Adrian Bullock]

A follow up question concerning upgrade possibilities.

We plan to do a Gradual migration, but have found out from the customer that there may be issues with following the suggested path for a Gradual Migration exactly as specified.

We have an AT environment with 2 application vapps and 2 provisioning vapps.  The suggested solution would be to upgrade these vapps to 14.4 CentOS6, add 4 new vapps running 14.4 CentOS Stream 8, and then retire the CentOS6 vapps leaving us with a 4-node CentOS Stream 8 cluster.

However, what we are considering is removing two nodes from the 14.4 CentOS6 cluster, so we are left with a single application and a single provisioning vapp running 14.4 CentOS6, then add two new 14.4 CentOS Stream 8 nodes using the exact same network information (IP and name) from the retired nodes.

We would then retire the remaining two 14.4 CentOS6 nodes and add a further two 14.4 CentOS Stream 8 nodes using the same network information from the last remaining retired 14.4 CentOS6 node.

By doing this the aim is that we end up with a HA setup running CentOS Stream 8 14.4 with 2 application vapps and 2 provisioning vapps but using the exact same IP and server names that were in use before the upgrade process was started.

Is this likely to work?  Apart from reducing the env to a single leg under the period of the upgrade are there any other issues we should be aware of if we reuse network names and IP addresses when performing an upgrade?

Thanks,
Adrian

[Shesh Pragada]

1. Reuse of IP address for the new nodes should not be a problem.
2. Make sure that before you remove a Centos6 node, the current cluster is functional. Reattaching a Centos6 node could be problematic.
3. Removal of nodes should be done via the web-console on the Centos6 nodes (Centos8 web-console is available for deployment only on pure Centos8 clusters)

[Adrian Bullock]

Thanks.

So in our case we will remove 2 nodes from the cluster originally, and go down to a 2-node CentOS6 solution (one app and one prov vapp).

Then we will add two new CentOS Stream 8 nodes.

Next we will shutdown the services on the CentOS6 nodes to ensure that everything works as expected with the CentOS Stream 8 nodes.

Then we enable the CentOS6 services again, and from one of the remaining two CentOS6 nodes we remove both CentOS6 nodes from the cluster.  So the last CentOS6 node is removed from its own web console???

This leave us with two CentOS Stream 8 nodes running the IGA platform.

Finally we add a further 2 CentOS Stream 8 nodes to the cluster, giving us a 4-node cluster again. 

Is that how it should work - being as explicit as possible at each step :)  Thanks.
Adrian

[Shesh Pragada]

The steps are correct. The last Centos6 node can only be removed from its own console.

[Adrian Bullock]

We have managed to upgrade all of our environments to 14.4 running under CentOS6, but the plans to remove the CentOS6 nodes and introduce CentOS8 nodes have been delayed (we only upgraded prod after summer).

By upgrading to 14.4 a number of bugs have been introduced to the platform, and now I am hearing from Support that CentOS 6 is not a supported platform for some of these bugs.

Given that the bugs were introduced by the upgrade process suggested by Broadcom above, and even encouraged (in place upgrade on existing hardware/infrastructure and then gradually introduce the latest vapp version), I am wondering what the official standpoint is regarding support of IDS 14.4 running on a vapp running CentOS 6?

Will issues introduced by the upgrade process be addressed? or is it the case that until the system is running under CentOS 8 Stream that Broadcom will not address any issues under CentOS 6 as this OS is deemed not supported?  And the suggested resolution path will be upgrade to the latest version using CentOS 8?

So to summarise, Platform v2 is the target environment, and Platform v1 is provided as a way of getting to Platform v2 gradually by upgrading rather than a fresh new installation.

My question is what (if any) support is provided for the Platform v1 environment for issues introduced by the upgrade process from 14.3 CP2 to Platform v1 on the Virtual Appliance (vapp)?

[William Cheang]

Hi Adrian, may i know what kind of issues or bugs was found after the upgrade ?

[Adrian Bullock]

Hi William,

We did an in place upgrade from 14.3 CP2 to 14.4 platform v1 using the provided patch file.

Issues encountered included/include:

In place upgrade of the Connector server does not work (the CCS service does not get renamed to Symantec as it should) - instead you need to completely remove the installed connector (with lots of careful dependency clicks form Services while doing this) and then install a fresh 14.4 Connector from scratch.

In place upgrade of Identity Governance from 14.3 CP2 to 14.4 does not work, as it seems to choose the default Oracle connector for some JDBC connections even when an MSSQL database is defined as the external database and the standalone file shows the correct configuration. Again this was resolved by removing the IG deployment and redeploying IG from the 14.4 installation.  Then everything worked as expected.

Tasks get stuck In Progress due to an ActiveMQ queue timeout and IM needs to be restarted to clear this.  When some tasks get stuck this affects the rest of IM negatively, hence the restart.  We have an open support case on this issue, and others on the forums here have confirmed similar behaviour.  It seems to be connected to HA/clustering, as we do not see this in our ST environment.

When going to the Branding pages of Identity Portal in the admin UI we see text appearing in chinese font.  We have an open support case on this issue.

Our wildfly logging is erratic and sometimes stops, and the only log we can really rely on is the wildfly-console log, which gets overwritten each time IM restarts.  We have an open support case on this issue, but so far it has not been reproduced by support.  We see the same behaviour in all three (ST, AT and Prod) of our environments.

When removing AD groups from a user, when two Connector servers are configured it can happen that while one Connector removes an AD group the other Connector replaces it as part of the same remove request.  When only one Connector server is used we do not see this issue.  This has been reproduced with ootb tasks.  We have an open support case on this issue.

I think that's all for now ...
Adrian

[William Cheang]

Hi Adrian,
Thanks for sharing, i think the issue with tasks get stuck in-progress have more impact on users. 
We are looking at in-place from 14.2 to 14.4 VAPP bcos customer does not have extra VMs. 

regards,
William

[Shesh Pragada]

Adrian/William

We can provide support on case-by-case basis. In general, the customer is expected to move to Centos8 platform once he has performed an in-place upgrade of Centos6.

You can open an issue and sustenance can take a look.

[Shesh Pragada]

We will provide support for only critical issues on 14.4 Centos 6.  Customers are expected to move to 14.4 Centos 8, once they have upgraded their older versions to 14.4.

[William Cheang]

Hi Shesh,
What if customer want to stay with 14.4 CentOS 6 after in-place upgrade, will vapp 14.4 with CentOS 6 still with CA support scope  ? 

regards,
William

[GThangaraj]

How we can access Centos web-console ? Is this managed by some other team?

[orawan tharavuth]

Hi Joffrey,
We plan todo the migration with these steps.
1. Setup new vapp 14.4 (CenOS8) with all 2 nodes where it point to the new DB 14.4
2. Restore the existing 14.3 DB to New 14.4 DB
3. We will add the New Vapp 14.4 to 14.3 Existing cluster
5. Remove Vapp 14.3 from cluster

Is this step correct or not?

[Joffrey Lemoigne]

Hi Orawan,



I won’t do yours steps as is (not a path that was certified and would need
some adjustments).



If you need at a certain time to have a cluster with old machines (CentOS6)
and new machines (CentOS Stream 8), the old machines should run 14.4 as
well and then, you should follow the Gradual Migration path (which consists
of patching the centos6 boxes to run 14.4, then install the new centoss8
boxes, then remove the centos6 boxes). More info at
https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/identity-suite/14-4/virtual-appliance/Migrating-Virtual-Appliance.html



If you need to use a new DB/cluster, you could use the side-by-side path,
mirroring 1st the 14.3 DB and install the 14.4 using this mirror. It’s
documented in the same link.



Hope that helps,

Joffrey.



*From:* orawan tharavuth via Broadcom <[e-mail]>
*Sent:* Sunday, October 22, 2023 1:44 PM
*To:* [e-mail]
*Subject:* RE: Symantec IGA : IGA 14.4 OVA platform & upgrade path



Hi Joffrey, We plan todo the migration with these steps. 1. Setup new vapp
14.4 (CenOS8) with all 2 nodes where it point to the new DB 14.4 2....
-posted to the "Symantec IGA" community

[image: Broadcom] <https: community.broadcom.com="">
Symantec IGA
<https: community.broadcom.com/enterprisesoftware/communities/community-home/digestviewer?communitykey="783a8a1e-bb2b-473a-a0c3-7be7b1d92c60">

Post New Message <[e-mail]>



Re: IGA 14.4 OVA platform & upgrade path
<https: community.broadcom.com/enterprisesoftware/discussion/iga-144-ova-platform-upgrade-path#bm063236eb-56df-4dea-8d61-a517162aa7b3="">

Reply to Group
<broadc[e-mail]?subject=re:%20iga%2014.4%20ova%20platform%20upgrade%20path>

Reply to Sender
<https: community.broadcom.com/enterprisesoftware/communities/all-discussions/postreply?messagekey="063236eb-56df-4dea-8d61-a517162aa7b3&ListKey=55a9ce74-6849-40d1-9be3-f37db03801e8&SenderKey=d89e30f6-4b5f-4801-a885-2c72c13727f4">

[image: orawan tharavuth]
<https: community.broadcom.com/network/members/profile?userkey="d89e30f6-4b5f-4801-a885-2c72c13727f4">

Oct 22, 2023 7:44 AM

orawan tharavuth
<https: community.broadcom.com/network/members/profile?userkey="d89e30f6-4b5f-4801-a885-2c72c13727f4">

Hi Joffrey,
We plan todo the migration with these steps.
1. Setup new vapp 14.4 (CenOS8) with all 2 nodes where it point to the new
DB 14.4
2. Restore the existing 14.3 DB to New 14.4 DB
3. We will add the New Vapp 14.4 to 14.3 Existing cluster
5. Remove Vapp 14.3 from cluster

Is this step correct or not?

*Reply to Group Online
<https: community.broadcom.com/enterprisesoftware/communities/all-discussions/postreply?messagekey="063236eb-56df-4dea-8d61-a517162aa7b3&ListKey=55a9ce74-6849-40d1-9be3-f37db03801e8">*
*Reply to Group via Email
<broadc[e-mail]?subject=re:%20iga%2014.4%20ova%20platform%20upgrade%20path>*
*View Thread
<https: community.broadcom.com/enterprisesoftware/discussion/iga-144-ova-platform-upgrade-path#bm063236eb-56df-4dea-8d61-a517162aa7b3="">*
*Recommend
<https: community.broadcom.com:443/enterprisesoftware/discussion/iga-144-ova-platform-upgrade-path?messagekey="063236eb-56df-4dea-8d61-a517162aa7b3&cmd=rate&cmdarg=add#bm063236eb-56df-4dea-8d61-a517162aa7b3">*
*Forward
<https: community.broadcom.com/enterprisesoftware/communities/all-discussions/forwardmessages?messagekey="063236eb-56df-4dea-8d61-a517162aa7b3&ListKey=55a9ce74-6849-40d1-9be3-f37db03801e8">*
*Flag as Inappropriate
<https: community.broadcom.com/enterprisesoftware/discussion/iga-144-ova-platform-upgrade-path?markappropriate="063236eb-56df-4dea-8d61-a517162aa7b3#bm063236eb-56df-4dea-8d61-a517162aa7b3">*

[orawan tharavuth]

Hi Joffrey.,

  Thank you for your suggestion.   

  1. we will use the Gradual Migration method.  Do u have the upgrade step in detail?

  2. How do we know, all configuration was sync to the new IDM VApp completely after added the new VApp to the cluster.

  3. one more, what if customer they want to replace the existing IDM DB with the new DB server because they want to update the windows OS to be 2019 and also SQL server. Do you have any idea or recommend? 

Thank you,

Orawan.

[Joffrey Lemoigne]

Hi Orawan,

#1 I don’t have the detail steps but the doc looks good to me:

Gradual Migration (RECOMMENDED)

To gradually move your existing Virtual Appliance deployment to 14.4 release, follow the given migration steps:

1.      Apply the upgrade patch on all the existing CentOS 6 or Amazon Linux 1 cluster nodes.

2.      Perform the following steps from the CentOS 6 or Amazon Linux 1 Web Console ONLY:

a.       Add new CentOS Stream 8 or Amazon Linux 2 nodes to the existing cluster.

b.      Deploy applications or services on the newly added CentOS Stream 8 or Amazon Linux 2 cluster nodes.

c.       Gradually, remove CentOS 6 or Amazon Linux 1 nodes from the deployment that are no longer required by clicking the "X" icon on each node and NOT by dragging and dropping each component out of the node.

#2 It’s similar as if you were deploying a new env. You go to the vApp console  management, Setup, you add the new machine to the cluster (I added -2 below), select the components to be deployed and click deploy. From here, you have to wait the end of the deployment once completed, you will get the message saying it’s done

#3 I never tested but the steps describe at https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/identity-suite/14-4/virtual-appliance/Change-the-Password-of-Symantec-IGA-Components.html, section Change Database Connection Configuration should do the trick.

As usual, the upgrade steps must be validated 1^st in a lower environment to make sure that everything is ok in your context.

Thanks,

Joffrey.