Pages

Rabu, 25 April 2012

Use PowerShell to help Outlook 2003 users view Exchange 2010 shared calendars

Takeaway: Derek Schauland offers a troubleshooting tip for those transitioning from Outlook 2003 to Exchange 2010 that corrects a problem with shared calendars.
Somehow I get the feeling that I am not alone when I say that I’ve only just recently completed a migration from Exchange 2003 to Exchange 2010. The migration went alright, but it seems some of the features did not work as expected. The latest feature that doesn’t necessarily make the jump to the new version of Exchange without some additional troubleshooting is shared calendars in Outlook 2003. This post will go through the reason for the issue (as I understand it) and the quick fix to get Exchange and Outlook to play nice again.

The issue

Outlook 2003 uses persistent RPC hooks into other mailboxes when viewing shared calendars (or potentially any other folder). Exchange 2010 naturally does things differently with regard to shared folders. Another interesting thing I found is that by default, the maximum concurrent connections via RPC in Exchange 2010 is 20. With a few calendars open by a few users, this can quickly become problematic. When this happens, users of Outlook 2003 will see things like the dreadful “Unable to open the folder, ensure you have the correct permissions” message when trying to view a shared calendar. Depending on the state of these persistent connections, sometimes there may not be a problem and calendars will open just fine, but eventually the users who weren’t having a problem in the beginning, will begin seeing the error message.

What can be done about it?

Since there isn’t a ton of support left for Office 2003, there are not a lot of places to look within the usual channels, although as part of a migration to 2010, you might be able to get a bit of help. However, the fix is somewhat simple and has a few parts to it:

Step 1

Because of the way Exchange 2010 handles RPC connections, you will need to create a new throttling policy for Outlook 2003 users and change the Maximum Concurrent RPC connections to a larger number. You can do this with PowerShell as it is not something available from the GUI.

New-throttlingpolicy -name Outlook2003 -RCAMaxConcurrency xxx

Where xxx is the number of concurrent connections you wish to allow. I went with 150 here and so far it seems to work fine.
When the new throttling policy is created, you will need to ensure that all of your Active Directory DCs know about the change through replication. You can let this ride and replicate with your usual schedule or replicate AD right away to ensure things get moving.
Following that, you will need to restart the Throttling service and the RPC Client Access Services (which may require your users to restart Outlook) on the Client Access and Mailbox Servers if your environment has more than one server for Exchange.
Now that the policy exists and Exchange 2010 can use it, we can move on to the next step — applying the throttling policy to user mailboxes.

Step 2

I am sure there are many ways to tackle this portion of the problem, but since I haven’t got that many users, I created a list users still using Outlook 2003. Once the list is completed and saved as a text file, off to PowerShell we go:
$users = "c:\users.txt"
Foreach($user in $users)
{
$current = (get-mailbox $user).throttlingpolicy
 If($current -eq $null)
{
 Set-mailbox $user -throttlingpolicy Outlook2003
}
$finished = (get-mailbox $user).throttlingpolicy
Write-host $user "now has the " $finished "throttling policy"
}
I saved this script as set-throttle.ps1 and called it from PowerShell by entering ./set-throttle.ps1 to change the policy for all usernames listed in users.txt
Note: When creating the list of usernames, make sure to remove any blank lines. Otherwise, PowerShell will try to use these lines, and there will be errors about users not found for all blank lines in the file.

Step 3

Make sure that the calendars in your environment have the right permissions on them. Setting a default of Reviewer should provide the read-only access needed to share these with other people.
Note: I included Step 3 as permissions because when I implemented this fix, there were mailboxes that had lost (or not enabled) the Reviewers permission for their calendar — just something to check if there are issues following the implementation.
There is one more step that the Outlook 2003 users will need to take. Re-starting any shared calendars they may be using. This will remove the existing persistent connection and allow a new connection to be established. To speed the process up, they can start outlook by entering the following in the run dialog:
 
Outlook.exe /resetnavpane
 
This will take the navigation bar back to the default configuration and remove any persistent connections to calendars. Then, as the user needs a calendar, they can re-open the shared calendar and all should be working as expected again.
Hopefully, this will help others get through the transition from Office 2003 to a newer version of Office.