Spurious firewall error at SharePoint Workspace startup

  • Article

Update, July 5, 2011: This issue is fixed in the the Office 2010 June CU for SharePoint Workspace. See this article for details: Office 2010 Cumulative Update for June 2011

 

Firewall error at startup - again

Some of our customers in more security-conscious domains have been noticing an issue with the SharePoint Workspace firewall exception check. At every startup, many users are getting a warning message that starts like this:

SharePoint Workspace is unable to communicate through your firewall and will run with limited functionality. To resolve this problem, enable SharePoint Workspace as a Windows Firewall exception...

(How it continues from there depends on your configuration.)

However, despite this message, SharePoint Workspace works through the firewall.

Why does this happen?

We want to warn the user if SharePoint Workspace is blocked by Windows Firewall, so when the program starts up, it makes the following checks:

  • Is Windows Firewall enabled?
  • If so, is there an exception for SharePoint Workspace in the local firewall policy?

If Windows Firewall is enabled and SharePoint Workspace doesn't have an exception in the local firewall policy, it returns an error to warn the user that program functionality may be limited.

But it works!

SharePoint Workspace only checks the local policies. Many organizations - especially ones that maintain tight security - manage firewall exceptions at the IT level and distribute them via domain policy. If you have a domain policy that pushes a Windows Firewall exception for SharePoint Workspace to domain members, the startup check will not see it. However that exception will work, allowing SharePoint Workspace to communicate through the Windows Firewall.

How do I stop it?

Although program functionality is not affected, this message still worries end users, and by requiring a user acknowledgment, it delays program startup. We recognize that this is a problem for many customers. For the moment, the best workaround is to duplicate the domain firewall exception to the local policy branch.