Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
If you are experiencing an issue with a single user, your first step is to determine if the issue is with the user or the device. Typically this can be accomplished by having the user enroll an additional device or by validating the users account is enabled to receive mobile email. Occasionally Exchange/Lotus/Groupwise, can experience issues with the ActiveSync paring.
Validating Active Directory/Exchange Account If you are using Exchange ActiveSync you need to validate the users account in Active Directory and the user's mailbox in Exchange. Make sure: The Active Directory account is not locked out or disabledThe users entering the correct passwordActiveSync has been enabled for the users' Exchange mailbox Troubleshooting All Devices Affected If you have more than one device/user effected, then it is important to test your ActiveSync endpoint in your browser to ensure that ActiveSync is working. Each email solution (Exchange/Lotus/Groupwise) has a different ActiveSync endpoint: Exchange: https://myseg.mydomain.com/microsoft-server-activesyncLotus: https://myseg.mydomain.com/servlet/traveler/microsoft-server-activesyncGroupwise: https://myseg.mydomain.com/Microsoft-Server-ActiveSync (Linux based solutions are case sensitive) Issues Applying POODLE Security Policies Several customers have had issues after applying SSL cipher and version configuration changes in order to ensure there servers are not effected by POODLE attacks. Most issues are related to having TLS 1.2 enabled but not having the appropriate ciphers enabled to allow TLS 1.2 traffic. Load balancers and reverse proxies can further complicate these issues especially since Unix based load balancers do not have strict cipher restrictions they adhere to. Your best bet to resolve the issue is to try the following: Try disabling TLS 1.2 but enabling TLS 1.1. If this resolves the issue then it is more than likely that one of your servers in your network is failing to negotiate TLS 1.2 traffic. Try enabling individual ciphers one by one (note you need to restart the server on order for these changes to take effect)Make sure your load balancers and proxies have the latest version of the software installed on themValidate that you have the latest Windows software updates Troubleshooting SEG Issues Proxying Email Troubleshooting Steps You first need to check to make sure that devices are not being blocked by the SEG compliance engine. You can confirm this from the Email dashboard in the console (Email → Email Dashboard) to make sure that the SEG is not blocking your devices.Test that hitting the SEG URL in your browser. The best place to test this is by using the external URL of the SEG. Make sure you include the ActiveSync sub-directory. Remember that each email solution (Exchange/Lotus/Groupwise) have different sub-directories for ActiveSync: Exchange: https://myseg.mydomain.com/microsoft-server-activesyncLotus: https://myseg.mydomain.com/servlet/traveler/microsoft-server-activesyncGroupwise: https://myseg.mydomain.com/Microsoft-Server-ActiveSync (Linux based solutions are case sensitive) If your browser returns a blank page, then the SEG is unable to establish a connection with your email solution. This is most commonly caused by performance issues on your email solution, networking rules, invalid SSL certificates and virus scans. You can verify the root cause of the issue by first attempting to connect to the ActiveSync endpoint of your email solution from a browser on the SEG server. The endpoint that the SEG is configured to use is setup during the initial configuration and is stored in a configuration file ({Install Path}\AirWatch\AirWatch X.X\AW.EAS.Listener\web.config). DO NOT CHANGE the setting from the configuration file. If you need to change the endpoint address please reconfigure the SEG through SEG Setup, which can either be found as a shortcut on your desktop, or by typing in localhost/segsetup into your browser. Troubleshooting Network Issues If the browser is unable to pull up the page at all you more than likely have a networking issue. You can also confirm this from the logs ({Install Path}\AirWatch\Logs\Listener\) by looking for the error message "The remote host has closed the connection" or "A connection could not be established with the remote host". Troubleshooting SSL Certificate Issues If the browser is able to pull up the web page but you receive an SSL error, then the SEG is unable to establish a secure connection with your email solution. In order for SEG to maintain a secure connection a valid SSL certificate needs to be present on your email solution. More than likely your SSL certificate has expired and you need to renew it with your SSL vendor. The SEG log will provide the error "An SSL/TLS connection could not be established" if you would like to confirm this issue in the logs. For more information on troubleshooting invalid SSL certificates, please visit the guide below: Troubleshooting SSL Certificates Virus Scan Exceptions Virus scan issues are difficult to identify due to how modern virus scans integrate into the operating system. To ensure that an issue is not related to your virus scan make sure the following exception is added (including sub-folders): {Install Path}\AirWatch\AirWatch X.X\* Issues Allowing Devices New Enrollments Are Not Allowing Devices Immediately If new enrollments are not being allowed immediately, but eventually allow the user (15-45 minutes) then you are more than likely experiencing one of two issues. Either your AirWatch device server cannot reach the SEG, OR in the event that you have more than one SEG you may be experiencing issues with clustering. You can validate whether on not the device server can reach the SEG by typing in the address of the SEG configured in the console in the browser on the Device Services server. This value is set under System Setting > Email > General. You will want to type it the following way: https://{SEGAddress}/SegConsole/Management.ashx?ping If this returns a blank page with an OK, then your application has the appropriate access to update the SEG. To confirm that SEG clustering is working, you will need to validate that each SEG is properly connecting to each other. This can be validated from the App Cluster Directory located in the AirWatch EAS Integration Service path ({Install Path}\AirWatch\AirWatch X.X\AW.EAS.IntegrationService\AppClusterDirectory.xml). You only need to validate this on one of your SEG servers. If all of your SEGs are not included then clustering is not working correctly. The easiest way to resolve this issue is to re-configure the missing SEGs to have the appropriate cluster configuration. New Enrollments Are Never Allowing Devices If your SEG servers never allow new devices, then your SEG server is not communicating with the APIs correctly. For new installations you may need to see an additional guide to continue troubleshooting. For all other instances try the following basic troubleshooting steps: Make sure the AirWatch EAS Integration Service on the SEG server is runningMake sure your network rules from SEG to your API server (usually Device Services) have not changedMake sure that your SSL certificates have not expired If the problem persists after basic troubleshooting steps are taken, please contact AirWatch Support. Blocking/Allowing Individual Devices Is Not Working If Allowing/Blocking devices from the console does not work, then you may have connectivity issues from the Console Server to SEG. Try to validate the steps mentioned in the first section (New Enrollments... Immediately) on your Console server.