cisco smart software satellite manager enhanced not synchronizing with cisco

[jaheshkhan]

cisco smart software satellite manager enhanced not synchronizing as scheduled. We scheduled for 30 days. but after 30 it will not automatically synchronize. every time we need to manually enter cisco smart account details and then synchronize. Why its only working manually and not scheduled? is there any thing missing?

Last time when i tried to synchronize  even that got failed. what do we need to do in this case?

[Vinod.s]

Hello ,

Hope port enabled for your CSSM IP - 

• User Interface: HTTPS (port 8443)
• Product Registration: HTTPS (port 443), HTTP (port 80)
• Communication to CSSM: HTTPS (tools.cisco.com, api.cisco.com, cloudsso.cisco.com), port 443

Refer Link : https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/212883-cucm-smart-licensing-mediated-model.html

Regards

Vinod 

[Scott Plank]

Have you figured out a solution? We just upgraded from v6.2 to v7.0 and still have the same problem. We can initiate a Standard Synchronization Now... under Actions in the Synchronization window, enter our credentials, and it works fine. However, the Scheduled Synchronization always fails.

The exact error message we get is "Synchronization Failed: There was a failure while synchronizing with Smart Software Manager."

Downloaded the full logs and am unable to locate any correlated entries in the 5 files that were included in the full log download (alerts.log, audit.log, messages, production.log, and secure).

[Vinod.s]

I think its a issue, Scheduling not working in my premises also..

now we are performing manual synchronization every month.

[jaheshkhan]

still same for me. nothing special i have seen. schedule never worked.
satellite manager still very buggy i felt.

[Scott Plank]

I opened a TAC case for this issue - got an excellent TAC engineer who was very thorough and knowledgeable. I have good news and bad news. The good news is that my server is now synching on the configured sync schedule every day. The bad news is that I do not have an explanation as to why it started working. Here are the details of what happened:

We upgraded a handful of 3850 switches to the 16.9.x train and converted them to Smart Licensing. That all went fine. Part of the conversion process involved having to force our on-prem server to sync with Cisco.com each time we initiated a DLC from one of the switches, in order for the traditional licensing on the switch to show up in our Smart Account. That all worked great.

After all was said and done, we did 8 forced syncs with Cisco.com (Synchronization Window > Actions > Standard Synchronization Now...)  the first sync (might have been the first 2 syncs, I don't remember now) prompted for our Smart Account credentials, the subsequent syncs did not. After that, our server began auto synching on the configured schedule every day. This was with our On-Prem server running on version 7-201907.

I do not know why it started to work - my best guess is that before we did the 8 forced syncs for the 3850 DLCs, we somehow got a wrong username or password combination that got cached by the server - on the next scheduled sync, it would fail, and because it failed, it somehow broke the sync schedule to where it wouldn't try again. Maybe forcing so many syncs in a short amount of time with the correct credentials forced the cached credentials to be refreshed with the correct ones and also somehow fixed the scheduled sync so it would now follow the configured schedule?

I should note one thing with the Scheduled Sync configuration (Synchronization Window > Schedules Tab > Synchronization Schedule section) - it is requesting a time in UTC, not local time. I did not notice this detail when we were first configuring our scheduled sync, so I assumed we would be syncing at 8:00am local time, but that ended up being 8:00am UTC, which is 2:00am local time.

[DionDohmen44084]

Hi Scott,

I am curious if your scheduled synchronization is still working fine?

I am experiencing the exact same issue, and at a certain point in time, I was able to get my daily scheduled synchronization up&running for 5 or 6 days, until it started to fail again...

[jaheshkhan]

Not yet. its been quite a while i didnt upgrade it to new version. so i just keep it as it is. client has not requested for upgrade yet. so didnt do it 

[drehstrom]

Hi guys,

has there any progress being made in this issue? I'm still having the same problem and this is quite annoying. To be blunt the crappy SSM On-Prem just sucks. From the very beginning we had nothing but problems. Since the invention of SmartAccounting the customer caring about IT-security is given a mess of pottage with half-assed solutions and then left alone.

I'm still convinced it's just a credential problem and I wonder why I don't need to enter any password when scheduling. I certainly hope this is not cached somwhere without the admin knowing and particularly not in plain text!

[Scott Plank]

Daily sync is still working for us, however, we have to force a sync about every month or so in order to maintain the daily syncing. I have to assume this is due to the server caching the credentials on the initial sync, then the cached credentials expiring after around 30 days. I wish I could say for sure, but documentation on this product is limited as far as the inner workings go. Even our TAC engineer did not know how it handled the credentials. We have the same concerns as you in regards to the credential caching, but find it a more acceptable risk than opening all of our networking equipment up on our firewall to sync to the cloud individually.

We also have an issue with devices not communicating properly with the on-prem server after their initial communication that we have not been able to figure out yet. The initial communication seems to work fine, but the renewals run into problems. We think it has to do with re-working our virtual accounts - we had just the default virtual account in our initial testing, but ended up creating two different virtual accounts. We think that because the key was generated in the default account, but the licenses were moved to a different virtual account, that the device is looking in the wrong place for the license. Hopefully, all we have to do is re-issue the key in the correct virtual domain. I guess we were hoping it would be "smarter" than that (pardon the pun). However, due to the limited documentation and support (we were told at one point that since this is a free product, the amount of support that Cisco will provide is limited, which is a response that I find to be lacking, to be polite), it really feels like we're beta testing the Smart Licensing on-Prem for Cisco, but even then, they don't care to improve or even support it. I feel like if Smart Licensing is going to be required moving forward, then Cisco needs to put more effort into their on-Prem offering.

I wish I had better news, but it is what it is for now.