Attachments blocked by email Management - wondering why
we're currently facing the issue, that attachments are not being forwared to the device and instead it shows a message that says ' Attachments blocked by email management' . Tested with word file 3MB, small pdf file and text file.
There's no limitation configured on the exchange server, so attachments are enabled and the max. size is set to unlimited. So I think it has something to do with the AW policies. SEG is configured and it doesn't make a difference wether compliance is enabled (with deactivated email security policies) or not. Attachments are still being blocked. And ' Get Attachment' is enabled in the advanced settings in mobile email management configurations. SCL is not installed / configured.
I don't know what we've missed checking or what it might be. Any thoughts?
No upgrade, it's a new installation with version 8.1. Users on the other airwatch server, older version with no SEG configured, don't have any problems and are able to get attachments. Same Exchange server.
We recently upgraded form v8.1FP01 to v8.1FP05. After the upgrade, the associates configured to use SEG, started to receive the same message 'Attachments blocked by email management' while the associates configured to use EAS did not have the issue. Within our SEG configuration, all of the compliance policies were disabled before and after the upgrade. However, we still were receiving the attachments being blocked message.
To resolve the issue, I went to [Email / Email Settings / Advanced] and unchecked 'Use Recommended Settings'. The Optional Transactions were no longer grayed out so I could uncheck 'Get Attachment'. Once unchecked, I clicked Save. Then I opened Advanced again, and then checked 'Get Attachment', and clicked Save again. After saving, our associates were able to start downloading attachments .
Note: Any previous emails that the attachments were blocked, were still blocked. It only addressed any new attachments apart new emails that were retrieved.
In our situation, the upgrade had to have changed the settings in the database and weren't being reflected by the GUI. Once we disabled and enabled 'Get attachment', it fixed our issue. Hope this helps.
However, we can close this question and mark it as solved. Obviously your post Deric was the answer to everything, it suddenly works fine for all devices. We disabled the compliance profiles and enabled them right afterwards. Maybe something was stuck there - now works. Thanks
We upgraded from 7.3 to 8.1.5 and had problems with attachments as well. We tried Deric's solution and did see some temporary improvements, but for us, some issues persisted. We later found out that the default AllowAttachments setting had been changed from true to false in the IntegrationService.exe.config file (on each SEG). So, any time our SEGs had problems talking to API, they'd assume that they needed to block attachments.
Actually, I ended up having to implement the config mods detailed in the instructions below. In my case, all attachments were being blocked. It wasn't until I made the suggested edits and restarted the EAS integration service that attachments began to be included w/ the message.
Attachments are blocked by Secure Email Gateway Feb 5, 2016 3:28pm Issue Description An email containing an attachment displays the attachment on a desktop, however, the attachment does not display on a mobile device. Mobile Email Management has been configured using a Secure Email Gateway (SEG). Issue Resolution Perform the following steps to ensure attachments are not being incorrectly blocked: Verify the SEG Test Connection in the console is successful Navigate to the SEG server. Open the EAS Integration Service config file (AirWatch X.X/AW.Eas.IntegrationService/AW.Eas.IntegrationService.exe.config by default). Make a copy of this file into a separate directory before making any direct edits. Find the line that contains Allow Attachments and set it to True. You can also alter the maximum size of attachments. Open the EAS Web Listener config file (AirWatch X.X/AW.Eas.Web.Listener/web.config by default). Make a copy of this file into a separate directory before making any direct edits. Find the line that contains Allow Attachments and set it to True. Restart the EAS Integration Service for the changes to take effect. If attachments were previously blocked or the maximum size was set too low, attachments should now send correctly.
This was a great help. One little odd thing to point out. I got on my SEG and the EAS Integration Service said ' Started' . However when I right clicked the only option I had was to ' Start' meaning it had stopped. Make sure you refresh your services when checking the EAS Integration Service.
Bilzin Sumberg Baena Price & Axelrod LLP
so i looked at this document. had to modify both files, and now my attachments are working... but my SEG still has the error for connectivity from the console. my devices, haven't connected ' under email' since the upgrade.. weird.
We recently upgrade to 184.108.40.206 and SEG v2 as well. We also see the error with the ' Connectivity from AirWatch to SEG' and opened a ticket. We got the information that everyting is fine in our environment and that it looks like a bug which exists since a longer time. The internal case was PR-195796 if you do wish to inform your AirWatch support person about the same issue.
Regarding the attachments which are blocked, make sure that your AirWatch SEG Server can reach the AirWatch API (for example installed on your console server). To check that open the URL ' https:///api/help' on your SEG. If that is working the SEG should be able to pull the configuration from the AirWatch API. If you couldn´t access the API you might have a firewall issue. It could be also that you have a proxy configured which blocks the access. So make sure that you defined the proxy and possible bypass lists via ' netsh winhttp set proxy ' (see: http://www.admin-enclave.com/en/articles/windows/211-set-proxy-on-windows-2012-2012-r2.html). Additional Check the AirWatch logfiles if you see an SSL trust error. This could come up when you do not use a SSL certificate from your internal Microsoft CA, then the server didn´t trust the connection and you might not be able to connect. But that will be also written in the SEG logfiles.