Hello!
One of those nitty gritty questions if I may?
If a system requires reactivating the license or not is determined by the data for the specific version being downloaded or the expiration date of your service contract with F5 (I think?)?
The re-activation process documented here:
But, if that’s the case, how did my colleague (let’s call him “Q”) manage this?
jamesbond@(MYLB)(cfg-sync In Sync)(Active)(/Common)(tmos) show sys license;show sys version
Sys::License
Licensed On 2016/10/18
Service Check Date 2016/11/21
Sys::Version
Main Package
Product BIG-IP
Version 12.1.2
Build 0.0.249
Edition Final
Date Wed Nov 30 16:04:00 PST 2016
As you can see, it does not seem like “Q” activated the license prior to upgrading to 12.1.2 as the service check date is
2016/11/21
while the KB article specifies
2016-11-29
. Though I would have expected the process to force him to do so upon reboot, but clearly this has not happened?
My colleague is a certified ninja so that might be the reason, but just in case:
What did I miss?
/Patrik
Hi, So as you already know or experienced in the past; it’s best practice to re-activate prior to an upgrade as the configuration “may” fail to load… And I quote from the solution article:
“If the service check date is missing or is earlier than the license check date, the BIG-IP system will fail to load the configuration when you attempt to boot into the upgraded software slot.”
Licensed On 2016/10/18<<< Service Check Date 2016/11/21***
Please let me know if I missed something or did not understand your question…
Alex
Hi and welcome to the forum!
Yep, I’m aware of it and I always do it. However, mr “Q” did not seem to have remembered, nor re-activated.
The article states “will fail”, right?
“If the service check date is missing or is earlier than the license check date, the BIG-IP system will fail to load the configuration when you attempt to boot into the upgraded software slot.”
It also says:
"Note: The **License Check Date**, as shown previously, and the **Licensed Date**, as seen in the bigip.license file, are not the same fields."
And the “License Check” date for version “12.1.2" is "2016-11-29” while my units License check date is “2016/11/21”. Even so, it is upgraded and the configuration has loaded successfully.
Please let me know if I misunderstood your answer?
/Patrik
That’s really interesting! grabs popcorn
You are right. I misread. Well, if its not behaving as documented, You can try and open a free support case… I don’t know the answer. Maybe there is a behavior change… I am out of suggestions 
For instance, in ASM, you can install signature updates if your last license re-activation was less than 18 months (1.5 years) ago. You don’t need to re-activate if this criteria is met. This also concludes that for 1.5 years, after your service contract has expired, you still have access to signature updates.
So in case of ASM signature updates, the formula is
if (Today <= Service Check Date + X) = you may proceed
where X = 1.5 Years. Let’s call X “mercy period”
I suspect there’s a similar “mercy period” involved in case of BigIP major software upgrades. Highly doubt it to be as high as 1.5 years, but your TMSH output strongly suggests that the true formula has more to it. Alternatively, the date documented in K7727 for 12.1.2 could be incorrect. Ask the MVP chat for a quick reply from F5 rep 
There may be a grace period for service Check date.
Thanks for trying anyway!
FMA, I’ll trade some of that popcorn for a beer?
/Patrik
Logged a support ticket. Stay tuned.
/Patrik
Any news? Running out of popcorn
Sorry, all I’ve gotten so far was a recap of what happened, nothing as to why.
Don’t worry, I won’t give up until this mystery is solved and laid bare for all to see. As a matter of fact, from today I’ll make it my life’s mission to get to the bottom of it!
/Patrik
The correct answer:
The date on version 12 was wrong. They will update the article.
/Patrik
Ok I got it now, irrespective of upgrading the guest or host, its always a good practice to re-activate the licences and in case of vCMP it has to be reactivated on the host.