2012-01-26 10:53 AM
As most of you already know there are a lot of bugs that prevent to send 8.1RC2 autosupport using an Exchange relay (2007 and 2010 but also 2003 as tested by myself).
And always as you know the 2240 FAS is shipped only with this DOT release!
This causes a lot embarrassment for us, ASP company, that have to say to the customer that us and them will not be able to receive their autosupport unlesse they install...a Sendmail (or some other Linux machine with STMP relays other than Exchange)...This is unacceptable and, let me say it, ridiculous in that environment where Exchange reigns...
Other source of embarrassment is due to the fact that to send an autosupport has always been a very easy action and now has become a nightmare due this silly bug that DOT does not end the message with CRLF.CRLF but LF (where's the programmer that forgot CR?!?)
To avoid any misunderstanding every fix and/or action has been done on the SMTP relays as from instructions...looking at its log the cause of bug appear clear...timeout on transmission for errors on format.
So: briefly. RC2 is supported and on the market since months...how much time do we have to wait again for a fix?
2012-02-10 05:26 AM
I can understand the frustration; FAS2240 requires 8.1, and 8.1 has not yet reached GA. Until a release hits GA no patch ("P") releases are created for it. So if you have a problem on an RC release you generally have to wait for the next RC release, or the GA release, to get the fix. You can also request a debug release ("D") if the problem needs to be fixed on an urgent basis. See the release model (http://now.netapp.com/NOW/products/ontap_releasemodel/PostJul2010.shtml) for more information.
This problem is tracked as bug ID 549239. According to to the Bug release tool (http://now.netapp.com/NOW/cgi-bin/bugrellist?bugno=549239) it is not yet fixed in any general release, although this tool does not include "D" releases that are provided on an as-needed basis only. You could inquire with support if a "D" release is available for your specific deployment, or you could wait for 8.1RC3 which is targeted to include this fix. Once 8.1RC3 is released I would verify in the same tool that it indeed fixed in that release.
Regarding workarounds it seems that ASUP via HTTP/HTTPS avoids this issue, as well as a host of other potential issues like email servers rejecting messages due to sender, size, antivirus gateways blocking attachments, etc. So if you have the ability to use HTTP/HTTPS it would be preferred anyway.
Hope that helps.
2012-02-10 06:04 AM
8.1RC2D6 does fix this....
Burt ID | Burt Severity | Title
549239 | 3 | SMTP encoding issues cause ASUP transmissions fail to MS Exchange mail servers
2012-02-10 06:29 AM
thank you for detailed answer but I would explain the main reason of disappointment and frustration
I can accept all the issues that can came from whater RC releas of any software. The things that I cannot accept is that in a "new" release adding "new" features the perfectly running old ones stop to do it...
Sending autosupport or (other bug) licensing some feature is a consolidated thing since 6.x DOT and I cannot accept to waste time supporting or explaining to customers the reasons of this failures.
About the shipping of 2240 without a GA release (also if supported) is all another stuff. In place of NetApp people I would wait before do it and I would put 8.02 on that filer.