CoNetrix

Blog: Office365

During my first attempt at installing the Office suite through O365, I began running into issues with the 'Invalid Security Certificate' warning popping up every few minutes after setting up the associates Outlook profile. This customer already had the proper GPO in place set to disable SCP look up, exclude httpautodiscoverdomain, etc, which had been effective at stopping this from occurring in the past with your standard Office install. After updating the ADMX files (which include a number of new Autodiscover policies) to the latest set in hopes of resolving the issue, the issue with the certificate warning continued to surface every few minutes. After doing some reading, I discovered there are two registry hives that can manage Autodiscover:
Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
Computer\HKEY_CURRENT_USER\Software\Policies\Microsoft\office\16.0\outlook\autodiscover

The latter Policies hive is where the key changes take place when managing via GPO, which was not performing the intended way with this O365 setup. I manually tested adding the Excludehttpautodiscoverdomain key to the first hive, and the security warnings stopped immediately. I tested disabling and enabling keys in both hives, and was able to confirm the finding. I have not had an opportunity to see if this issue exists for any other workstation/customer, but hopefully someone might find this useful if they do. I wound up just adding this key in via the registry via GPO and had no further issues after it was applied.

Office365,
 

One of our customers was having problems connecting Outlook to exchange accounts hosted with Microsoft through their Office365 program. The machines in the domain running Windows XP with Office 2007 had no problem connecting, but none of the Windows 7 machines with Office 2010 were able to connect. Since the email accounts were hosted at Microsoft, Outlook was using port 80 web traffic to establish a connection. After exempting the source IP of the test machine from filtering in the Barracuda, the connection immediately worked. This proved that something was not working correctly inside the Barracuda.

The domain outlook.com was whitelisted prior to these changes. After talking to Barracuda tech support, they found several IP addresses that Outlook was trying to contact. They suggested adding those IP addresses to the list of IP addresses that bypass the Barracuda, which is the proxy server, and opening port 80 for those IP addresses on the firewall. We made the suggested changes and it worked correctly. The Barracuda engineering department found that the traffic to outlook.com was being redirected to live.com, and therefore being dropped by the Barracuda. Barracuda suggested we add an expression to the Barracuda to allow port 443 traffic to live.com, but they later said we would probably have to whitelist live.com for this to work properly. We chose to just leave port 80 open to those IP address on the firewall and have clients bypass the proxy for those addresses.
 
When troubleshooting issues that might be related to the Barracuda, it is often helpful to temporarily exempt the source IP of the machine on which you are working. When the Barracuda is in Forward Proxy mode, this can be done by going to Advanced > Proxy. Add the IP to the Source IP group under the Proxy Authentication Exemptions.

Networking, Barracuda, Outlook, Office365, Windows 7,