Showing results for 
Search instead for 
Did you mean: 


Service item for License

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.



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

HInts ?

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: -

Error Saving Form

  • The service form could not be submitted because of following error: Invalid Values 1000000,1000000,1000000,1000000 for dictionary field LicenseInfo.MaxVDCperOrg

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. 

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.

Hi all

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.

Best regards

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 -

  1. IAC 3.1.1 Hotfix 1 - addresses common configuration pitfall as described in IAC 3.1.1 Hotfix 1 Technical Note and by Blaine Lincoln above.
  2. TEO 2.3.5 Hotfix 11 (to be released shortly) - addresses a race condition that is most noteably affecting IAC licensing processes.

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.


Hi all

Just noticed there are three hotfixes avaialble for orchestrator 2.3.5 (11, 12 and 13). Does any of them address this issue ?



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.   

Erly Thornton
Cisco Employee

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.