Microsoft Entourage 2008 for Mac, Web Services Edition is a required upgrade if you are using Exchange Server 2010. Entourage 2008 (without EWS) uses WebDAV to communicate with Exchange Server and WebDAV has been removed from Exchange Server 2010. Entourage EWS now uses Exchange Web Services (EWS) as the primary protocol for communicating with Exchange Server. This means that Entourage now can potentially access all the information available through EWS.
So what about Public Folders? According to the Entourage EWS documentation Entourage can now access Public Folders, but there is no mention of whether Entourage needs Public Folders. Entourage without EWS did absolutely need Public Folders. During Exchange Server 2007 installation you got a question; Do you have any client computers running Outlook 2003 and earlier or Entourage in your organization? If you answered yes; a public folder database would be created. If you answered now; no public folders in your organization. Since Entourage EWS now can access free/busy data through EWS there should be no reason to continue having Public Folders in your Exchange organization. But I have been unable to clearly determine if that is the case. Right now I think it is unnecessary, but I will do some further testing.
I recently upgraded to Exchange 2010 on my home network. Everything went well, but when I started the Exchange Management Console for the first time I got this error when trying to open the Server ConfigurationClient Access node:
—————————
Microsoft Exchange
—————————
Connecting to remote server failed with the following error message : The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic.
—————————
OK
—————————
After looking at the various settings for WinRM, firewall etc, I noticed that the WinRM IIS Extension was missing from my features list. I added it through Server Manager:
I could have used ServerManagerCMD.exe as well, but it has been depricated. The command would be:
servermanagercmd.exe -install WinRM-IIS-Ext
Or the PowerShell Server Manager cmdlets:
Import-Module ServerManager
Add-WindowsFeature WinRM-IIS-Ext
After the feature had been installed the error disappeared and Exchange Management Console worked without incident.
I had originally followed the steps outlined in
this article on TechNet to install the prerequisites for Exchange on Windows Server 2008 R2, but those instructions do not mention the WinRM IIS Extension.
NOTE: Disregard the info in this post for now. It has come to my attention that this might not always work and therefore requires some more research. Sorry!
With the introduction of Autodiscover in Exchange 2007 this might not be very relevant, but some users still use PRF files or the Office Customization Wizard to pre-stage settings for uses’ Outlook Profiles. Whenever you use one of these methods, or if you create your Outlook profile manually, you will be prompted with a list of users in the Global Address Lists that match your username. E.g. if you username is paulo and another user’s username is paulos, Outlook cannot uniquely identify you and prompts you to select which user is you. This can be a problem for users who are likely confused by the list and also a source of errors since the possibility exists that the user will select the wrong entry. This last case will result in an access denied error since the user does not have access to the selected mailbox.
To work around this you can add the default SMTP domain to the %username% variable specified either in the PRF file or the Office Customization Wizard. There cannot be two users with the same SMTP address in you organization so this will uniquely identify the user. Note that this approach requires each user to have an SMTP address in the form <username>@<SMTP domain>.
Information wants to be free!
