What you have to watch out for is a mismatch between the ID on the subscriber data and the ID/permissions being used to retrieve the data. If they don’t match, you get dupes. It isn’t as simple as “admin” or “nsapi”. The crux of any duplication issue is that PO is unable to read the existing records in the CP license data table. 100% of troubleshooting should revolve around that assertion.
In the 3.1.1u1 (TEO 2.3.5 HF10) hotfix, we started hardcoding the nsapi user on the subscriber data, so we no longer inherit the channel ID subscriber data. This eliminates failures when the SIL service is inadvertently run as admin. Its easy to make that mistake as it turns out. Additionally we check the ID that we are going to subscribe the SIs to, and make sure it is a member of the cloud admin OU. This should prevent writing bad data.
Because of these changes, there should be no need to clear the cached channel ID anymore. You can do it if it makes you happy. It won’t hurt anything. However, it won’t help you get to the root of the issue either.
You should:
- •1. Apply the hotfix so that you get the goodness described above.
- •2. Check carefully your runtime users in PO which talk to CP. This includes BOTH the integration API user, and the CP standard target user. We see these get messed up frequently.
- •3. Check the extended target property described in the tech note we published yesterday. (service targets, nsapi login id)
- •4. Make sure that the 3 users referenced above are all the same user that you intend to use via nsapi. Then look in CP and make sure that that user is both a CPTA and a Site Admin (not inherited) and has a home OU in the cloud admin org that you created.
- •5. Remove ALL the records in the license table. This sometimes means multiple pages of them. Get all of them. There is no risk associated with doing this. There is risk if you try to pick through it manually.
- •6. Run the license service. You can find it in the config wizard, the about page, or if you go to my services and search for services containing “license”. You can also do it by going to PO and running “manage license data”, but please prefer the CP based methods. That is where we want our end user interaction to be. If you do not run the license service, just go have a nice lunch. It runs hourly, so it should have run by the time you come back. After it runs, you should have exactly 9 records in the license table.
- •7. Run the license service again. You should still have 9 records, and the timestamp should have changed. So should the GUID on the last refresh reason.
If that doesn’t work, you should let me know so I can webex with you. This is something that we want to have work well and reliably, so that our product makes a great first impression and our licensing is not intrusive. There will come a point where I will ask you to open a TAC issue, but for the next week or so, feel free to ping me directly so that I can help you get in front of it faster. If you are on a timezone outside of the US, fear not. I have a new baby at home, so I am up at all hours of the night anyway. I may as well spend my time helping my colleagues maximize their success.
