Hi all. Quick question:
Is there any problem if I remove all lines from the System Setup -> System Service License and them request a new license refresh at the portal? I'd like to do it if that would not break anything. I'm still installing CIAC and that action would not stop anyone's work.
Solved! Go to Solution.
Well, I've spoken too early: the patch and the solutions here did not solve my problem. Periodic refresh keeps removing lines it should not remove. The license information at the license popup shows "undefined" for that data.
If I remove all lines from the service item and force a refresh, it will be correctly populated. Periodic refresh is breaking it.
I've installed hotfix 10 and followed the directions in
For me, after installing the hotfix, the fix was checking the 2 targets had nsapiuser instead of admin fixed it as per Troubleshooting License Failures
It's worth trying I guess?
Well, it looks like I've fallen for it also as I'm now getting this following message when ordering a new VDC: -
Considering I have applied the HotFix and followed the necessary follow up actions Troubleshooting License Failures, I guess we have a bigger issue here?
What do you think?
The key may still be in the global channel ID that is used for license management. If the license data is still assigned to "admin", that remains the issue.
As previously recommended, please clear out the value in the global Channel ID in PO and then order "Cloud SIL Update Channel ID" from My Services logged in to the portal as "nsapiuser"
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.
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.
I'm afraid to say that I've applied the patch but it did not solve the problem. Not only that: looks like it added another bug, totally unrelated. I've just fixed the extra bug it added but I'm not able to fix the original problem yet.
I'll detail the extra bug in a separate post. By the way: isn't anyone provisioning machines through CSP? This extra bug is related to it.
A specific question here:
Where do I find that channel ID mentioned here? Is it the "Cloud Service Item Update Channel ID" global variable?
Even aftar applying the patch the license problem remains. I think I haven't explored the option of blanking that value.
Yes, that is the global channel ID. Forgive me if this mentioned above, but have you tried just deleting all the entries in the License SI and logging in as a the nsapi user and running the refresh? You can also just assign the records manually. Not a fix, but quickest way to get you moving on. Also, as I mentiond in a previous post, as a safety precaution, check and make sure the runtime user credentials for all 3 of your cloud targets are set to the nsapi user.
Hope this helps.
Otavio, further diagnosis of the issue experienced here has uncovered a defect in the Orchestrator. Symptoms of this defect manifest itself in the form you're experiencing with IAC product licensing. To eliminate your woes entirely, it'll take a two-punch combo -
Well ... looks like I'll have to wait for this next hotfix release. I've tried everything we discussed here but the problem remains.
Thanks for all the support.
Just noticed something interesting:
I've deployed it in three customers and the problem did not occur in one of them: the only one without AD integration.
And the problem remains in the two deployments where AD integration exists- even after applying the tidal hotfix 10 and other workarounds suggested here.
People in this thread
I still could not have this problem fixed. License information goes messed at every new license refresh. I've followed the instructions suggested here but the problem remains.
Looks like there is no new patch/hotfix available that addresses this issue, right ?
Thanks in advance
Otavio, yes, you'll want to deploy IAC 3.1.1 Hotfix 1 (PO 2.3.5 Hotfix 10) and PO 2.3.5. Hotfix 11. It's the combination of both of PO 2.3.5 Hotfix 10 and 11 that address this license issue.
I applied the hotfix back in March and it worked fine. Last month the issue re-appeared. I have reapplied the Hotfix and applied troublshooting steps but after a day or so I end up with multiple records again in this table. What are the triggerers or inputs for this? Is it possible that there are earlier license refresh requests still running? So far I have 7 requsition IDs in this table. When I first cleared and submitted I had only 1.