We've had the same problem since yesterday.
This vSAN health check has a warning threshold of 90 days and an error threshold of 180 days.
And as far as I know, the release catalog will only be updated when there are new patches and releases. And it seems that there have been no new patches or releases in the last 90 days.
Therefore the release catalog was not updated during this time and now the vSAN health check complains that the release catalog is too old.
"And it seems that there have been no new patches or releases in the last 90 days."
Sure there have been patches in that time - last ESXi patch was released 36 days ago:
There are numerous different reasons why this won't/can't update - start by checking the date of the one in use, if it is old then get a current one, if it remains using an old one when you are manually applying a current downloaded then it isn't updating. Some common causes here:
If you have internet access from the vCenter then try updating from the vCenter in the HTML5 Client if 6.7 U1 or Health alert in the later 6.5 versions *IIRC*, if it is not pulling the current one and you have proxy configured then you may need to ACL more than just the myvmware login address, if you don't allow *.vmware.com then check that these are accessible:
If 6.7 U1 and vCenter is internet-connected and the above is not working after sorting any proxy issues try changing the defaultmetadataurl:
In my case VCSA has internet connection and can reach all the mentioned URLs and I've also added the metadataurl parameter to the health check config file.
But I have a copy from the release catalog file from 2 months ago and it's exactly the same as of today:
And if you check the arrival and processed date in the release catalog json file from above URL, you will see it's from 12/11/2018.
has a higher processedDate - I wonder is the other address now an 'old' one.
I found it here:
Currently no 6.5 U2/6.7 U1 labs at home here (don't even ask but complete wipe-down was needed ) so I can't check now - did you check if applying the one with 'deploymentId=tba4919b-2dce-f4585-9556-a780bb9ac060' as the defaultmetadataurl resolves this by pulling current one?
The file worked for me, my catalog is up to date (2019-01-29)!
Great to hear - should work as downloading that if offline or setting it as defaultmetadataurl if online so.
Now to figure out is that one latest and is it being updated or will that be 'old' and trigger alarm come the end of April, either way I will get the kb(s) changed to that one for now when back in the office.
Both of the metadata urls contain the same json data. For ease of refereence :
This is the original url that was in the vcsa config.conf file released with v6.7.0. As docuemented in the thread that theBobkin refers to this url contained a broken reference for v6.7.0 U1. Vmware did two things to fix this. First they provided a new json file at a new url, which is URL#2 below. Secondly they removed the broken references in the json file at URL #1.
This is the URL that replaces URL#1 and is referred to in the kb's previously referred to (58891 and 60393).
Now both URLs contain the same json file. That is nice - thus folks that didn't get the memo that the original url was filled with bad data and that there is a new url no longer have to update their config.conf file with the new url.
However that json file was put up on the web over 90 days ago. Thus the alert that is happing now. It is true that new patches have been released in the last three months but the release catalog db is not used for VUM patch downloads. Those are handled via a separate method - my system checks for patches every night and gets them. Thus even though my release catalog db file is now over three months old I have received automatically the patch ESXi670-201901001 with build ID 11675023 released in Jan 2019.
So, bottom line is both url contain the same catalog data, it is over 90 days since it was last updated, and it is [probably] okay if you are getting patches downloaded automatically on a daily basis.
It would seem a colleague of mine had the lead on this issue prior to me looking at this here on Communities - the defaultmetadaturl JSON referenced in the kb articles now is current date (e.g. today Saturday, March 9, 2019 - epoch 1552098659000). So using the defaultmetadataurl as per the kb articles should be fine.