My Autosupport seems to be working internally. i.e. it sends to the recipients defined in the AutoSupport options.
However the My AutoSupport on the NetApp site shows ASUP as disabled. The 2 filers have generated a Weekly_log on Sunday but the ASUP online still shows as disabled.
This is a new install of a 3210 cluster and the filers both have internet access to POST to the netapp auto support URL. they can ping support.netapp.com.
I need a way that I can generate a Weekly_log so I can test it. Is this possible?
Any hints appreciated.
I would suggest to first try out a user triggered AutoSupport with the subject having the word "test" in it and see if NetApp sends a confirmation e-mail back to the listed contact. In 7-mode, this would be "options autosupport.doit test". The word TEST in the subject enables the NetApp e-mail acknowledgement mechanism.
If that works, I would have high confidence that the weekly AutoSupport will work since the majority of the workings involved are duplicated with that test.
If there is something truly unique about the weekly AutoSupport then the only way I know to cause that exact behavior is to set the time on the filer forward (not backwards) to Friday night at 11:30PM local time on the filer and wait about an hour (maybe 90 minutes) for it to trigger the AutoSupport and send it.
I tried a 'Test' autosupport and we did not receive a response back rom NetApp.
We are using ONTAP 8.0.2
Looking through, am I right in thinking we need the SP port configured for it to be able to send out to NetApp? as I have an error when I do the test of:
The network configuration of the Service Processor (SP) failed due to cable or network errors.
As far as I know, the SP configuration and state doesn't control Data ONTAP's AutoSupport or impact it. The Service Processor has its own AutoSupport and its own network and uses Data ONTAP's configuration information for helping configure it (not the other way around).
Focusing on Data ONTAP is what I would do.
I would focus on the user triggered AutoSupport. If none are showing up in the now.netapp.com MyAutoSupport viewer (https://now.netapp.com/NOW/asuphome/), I would suspect a networking problem first and a configuration problem second.
For quick help, I would look in the <root volume>/etc/messages file and check out all "asup.*" lines and see if there are any issues and helpful error messages saying things about HTTP, HTTPS or POSTing.
Alas, the next steps are more difficult. In a future release, we have significant improved AutoSupport by providing a transmission history report and other commands. In 8.0, one needs to drop into diagnostic shells and do commands such as "telnet support.netapp.com 80" and see if it connects (without a banner or other response). This is a very unforgiving access level where mistakes or misunderstandings can lead to extended downtime and other issues.
I would open a support case with NetApp.
After double checking the options I found that autosupport.support.enable was set to off!
I had missed this and had only checked autosupport.enable was on. Anyway I set autosupport.support.enable to on and the ASUP are now working and I have confirmation from NetApp.
Thanks for your help.
A cool trick is to call the test autosupport "WEEKLY_LOG" and it will update the my autosupport site witht he latest asup too... so if you want the latest processed now instead of waiting until Sunday.
For Data ONTAP 7G, the cool trick described of "options autosupport.doit WEEKLY_LOG" gets most of the same content. This is disappearing quickly in 8.0 and later releases.
I’m glad to hear that you found the config error…
BTW, please consider plugging in your wrench port. It gives you access to e0M to directly manage the system and allows you to leverage all of the remote management and remote support capabilities of the Service Processor.