Outlook Free/Busy option

Question

I've installed and cofigured SunOne Calendar Server 5.1.1 and I have a problem. In the Outlook's Free/Busy option, in the box search at this URL I enter the follow (as I've read in the documentation):
http://nameserver/get_freebusy.wcap?fmt-out=text/calendar&tzid=America/Chicago&mail=%NAME%@%SERVER%
Then, when I check the availability of a Calendar Server user does not work, it appears "no information" for this user. In the Calendar server, there is this error in httpd.log:
[21/Jan/2004:12:54:21 +0100] srvmail cshttpd[3070]: General Error:
calstore_fetchcomponents_by_range(): call to ac_fetchcomponents() returning err = 39.
[21/Jan/2004:12:54:21 +0100] srvmail cshttpd[3070]: General Error:
calstore_fetchcomponents_by_range(): db error (pError->iErr) = 39.
Thank you in advance,
Esteve

Answer 1

Pat,
Leif-Arne's script will modify the permissions if the manager already has rights to the calendars.  However, if the manager has a direct report who hasn't granted any access to him, it will need a slight modification.  Here's an updated script
that will handle the add rights where they don't already exist, while modifying them if they do.  I'm using Leif-Arne's script as the basis, but I'm simplifying it in places to streamline the code.
$ManagerAlias = (Get-Mailbox "UserName").Alias
(Get-User $ManagerAlias).DirectReports | Sort Name | Get-Mailbox | Sort Alias | % {
    $Calendar = Get-MailboxCalendarFolder -Identity "$($Mailbox.SamAccountName):\Calendar"
    Add-MailboxFolderPermission $Calendar.Identity -User $ManagerAlias -AccessRights LimitedDetails -ErrorAction SilentlyContinue
    Set-MailboxFolderPermission $Calendar.Identity -User $ManagerAlias -AccessRights LimitedDetails -ErrorAction SilentlyContinue
Note the last two lines of code are using the -ErrorAction SilentlyContinue
parameter. This saves code where you would check for the manager's name in the list of accounts that currently have rights on the mailbox. If his name isn't in the list, it will be added by the first of these statements. If it is, the first statement
will throw an error, but it will be ignored. The second will always succeed, since the manager's name will by this point always be in the list.  However, since there is a chance that the second command may be run against a different domain controller,
it may throw an error.  In this case, the error handling is there just in case.  I will add that when it uses the same domain controller, you will probably get a warning that nothing has changed on the mailbox.  These can be ignored - if you
have PowerShell 2, you can't block them successfully.