I know this is old, but I ran into this as well when upgrading from v6.5 to v7.0 U3 so I figured I'd post this in case it helps anyone else who comes across this. The article the OP posted links to another article that describes a fix for this issue (https://kb.vmware.com/s/article/2050273), however this didn't help for me because I didn't have duplicates of the vcenterserver service registration (which is the only type of service that the article tells you how to check for). However when I re-ran lstool.py as described in the article but without the --type parameter (to show all service registrations of all types) it showed that I actually had a duplicate cs.identity service. Another place where you could find details on which service is the duplicate would be in the /var/log/vmware/upgrade/requirements-upgrade-runner.log file on the appliance (search for "duplicates").
Apparently this can happen when you have a system that was previously on v6.0 and was then upgraded to v6.5 or v6.7 (after seeing this I checked another instance that had upgraded from v6.0 to v6.7 and indeed it had the same issue) - I haven't found this documented anywhere really other than a hint that it may have been mentioned in a presentation from VMworld 2019. From reading various threads, it seems many people just click through this warning and upgrade anyway and it goes fine, but you never know if it might come back later to cause some weird/hard-to-troubleshoot issue so I figured I should try to fix it.
So in any case, I had to unregister one of them to resolve the issue. The question is - how to know which one to unregister? Well I happened to have another instance that had been originally deployed at v6.7 and later upgraded to v7 (therefore it was not subject to this issue), and I checked the service list on that (via lstool.py) and confirmed what the "correct" instance of the cs.identity service should be on a v7 VCSA. If you look closely at the two instances on the problem VCSA, you'll notice (from the lstool.py output) that one has two extra endpoints beginning with /idm and /openidconnect (e.g. https://vcsa-fqdn/idm and https://vcsa-fqdn/openidconnect/...) which the other instance does not. From checking the "clean" v7 box I was able to see that the instance with the /idm and /openidconnect endpoints present on it was the "correct" instance of this service that should be running on a v7 VCSA (on a VCSA that was originally deployed from v6.7 or later it would be the only cs.identity instance). Therefore I could deduce that the other instance, without those two endpoints, is the one that needed unregistering from my problem VCSA. To be safe, I first backed up the service registration to a "spec file" so I could try to restore it in case something blows up:
/usr/lib/vmidentity/tools/scripts/lstool.py get --url https://localhost/lookupservice/sdk --id "[serviceID]" --no-check-cert --as-spec > /tmp/old_cs.identity_service_spec.txt 2>/dev/null
Then I unregistered it w/ lstool.py using a command like so:
/usr/lib/vmidentity/tools/scripts/lstool.py unregister --url https://localhost/lookupservice/sdk --id "[serviceID]" --user 'administrator@vsphere.local' --password '[password]' --no-check-cert 2>/dev/null
[serviceID] here should be the ID of the cs.identity service registration that you want to remove (the one without the extra endpoints I mentioned) and [password] is your administrator@vsphere.local account password. If successful it should return no output. You can then use it to list all services again and should see that you have only one instance of the cs.identity service now, and if you re-run the upgrade pre-check you shouldn't get the warning anymore.
