With a default installation of Exchange 2007, when an Exchange 2003 user tries to open/view the shared calendar of an Exchange 2007 user they receive the error “Unable to display the folder. The Calendar folder could not be found.” This error is received because the Exchange 2007 server rejects the MAPI request from the user’s Exchange 2003 server. Adding the following registry value will allow the Exchange 2007 server to accept these requests from 2003 servers:
Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Value Name: Disabled MAPI Clients
Value Type: REG_SZ
Value Date: -6.4.9999
The value “-6.4.9999” will allow Exchange 2007 servers to accept connections from Exchange 2003 and all versions of Outlook.
You can read more about this setting at:
How to disable MAPI client access to a computer that is running Exchange Server
http://support.microsoft.com/kb/288894
Technet: All versions of Outlook are allowed to access the server
http://technet.microsoft.com/en-us/library/69e7ac7b-9f0b-4b0d-879a-334c1b41242b.aspx
--Nick
Thursday, May 24, 2007
Sunday, May 6, 2007
Exchange 2007 Clustering: Important KB articles
Kerberos Authentication
Kerberos authentication will not work on an Exchange 2007 clustered server (CMS and SSC) until each cluster node machine is granted permissions to write the ‘Validated-SPN’ property on the CMS Active Directory computer object. Additionally, the following error messages will be entered into the Application event log.
Event Type: Error
Event Source: MSExchangeSA
Event Category: General
Event ID: 9317
Date:
Time:
The KB article ID 935676 details the process of granting this permission on the CMS computer object.
Event ID 9317 is logged when the Microsoft Exchange System Attendant service comes online on an Exchange 2007 cluster node
Provisioning mailboxes on additional Single Copy Cluster nodes
If you are creating a multiple CMSs (Clustered Mailbox Server) in a Single Copy Cluster you should be aware of the following KB article. When trying to provision a mailbox on a second or successive CMS you receive the following error:
“A proxy generator DLL on server FQDN.serverName could not be found or failed to initialize. Proxy addresses for the current recipient cannot be calculated. Please ensure that all the proxy addresses for the current recipient cannot be calculated. Please ensure that all proxy address generator DLLs have been installed on the target server.”
This error can be solved by creating a message transfer agent (MTA) in Active Directory for each CMS.
How to enable mailbox creation on the second or later clustered mailbox server (CMS) of an Exchange 2007 Single Copy Cluster (SCC)
--Nick
Tuesday, May 1, 2007
Managing Resource Mailbox Calendars
The Set-MailboxCalendarSettings cmdlet is one of the most useful and flexible cmdlets available with Exchange 2007. However, its flexibility often leads to complexity and confusion. I’ll do my best to walk you through the possibilities and help explain some areas where the Microsoft documentation is lacking.
Let’s start off by getting the calendar settings of a resource.
You will see the identity of the resource and its AutomateProcessing type. This can be set as one of 3 possibilities:
AutoUpdate is the default value for all mailboxes to help users manage their calendar data. The AutoAccept processing mode can only be enabled on resource mailboxes.
From http://www.microsoft.com/exchange/evaluation/features/default.mspx each attendant is defined as the following:
Now we explore the great flexibility this cmdlet offers (and the root of that flat spot on your forehead from repeating banging it against the wall). There are 3 distinct, counter-intuitively named policies that can be defined for automatic calendar processing:
If you want to get fancy you can use the following command to allow all users to submit in-policy requests while allowing user1 to submit out-of-policy requests and adding the ‘Executive Committee’ distribution group members to the book-in policy.
The Set-MailboxCalendarSettings cmdlet allows the administrator to define resource delegates without having to manually configure an Outlook profile and navigate the appropriate menus to define delegates. The feature is one of my favorites and very useful for self-service applications. However it has been a bit buggy. Here are the two bugs I have identified and should be fixed in SP1.
In additions to the features offered by the resource booking attendant there are many other calendar customizations that can be defined. Below are a few useful options that we use all the time. A complete list can be found at http://technet.microsoft.com/en-us/library/aa996340.aspx.
If you fear the command line like some of my co-workers (you know who you are… Jon) you can manage most of these settings via connecting to the resource mailbox via OWA and editing the ‘Resource Scheduling Options’. You have the ability to manage all of the calendar settings you would from the command line with the exception of defining resource delegates.
To open the resource mailbox via OWA you must define full-mailbox access to the managing user. This can be done from the Exchange Management Shell with the following command.
--Nick
AutomateProcessing
Let’s start off by getting the calendar settings of a resource.
[PS] C:\>Get-MailboxCalendarSettings demo_laptop_1
Identity AutomateProcessing
-------- ------------------
ColoState.EDU/ExchangeResources/Demo Laptop 1 AutoAccept
You will see the identity of the resource and its AutomateProcessing type. This can be set as one of 3 possibilities:
- None
- Both the resource booking and calendar attendants are disabled.
- AutoUpdate
- Only the calendar attendant is enabled.
- AutoAccept
- Both the resource booking and calendar attendants are enabled.
AutoUpdate is the default value for all mailboxes to help users manage their calendar data. The AutoAccept processing mode can only be enabled on resource mailboxes.
Calendar and Resource Booking Attendants
From http://www.microsoft.com/exchange/evaluation/features/default.mspx each attendant is defined as the following:
- Calendar Attendant
- The Calendar Attendant reduces scheduling conflicts by limiting calendar items (request, declines, accepts) in the inbox to the latest version. The Calendar Attendant also marks meeting requests as tentative on recipient calendars until users can act on the request and relies on the Exchange Server 2007 free/busy Web service for always up-to-date availability information.
- Resource Booking Attendant
- The Resource Booking Attendant enables resources, including meeting rooms or other equipment, to be automatically managed. Resources can auto-accept requests when available or decline and provide details explaining the decline. Administrators can set granular policies on resources, including available hours or scheduling permissions.
Calendaring Policies
Now we explore the great flexibility this cmdlet offers (and the root of that flat spot on your forehead from repeating banging it against the wall). There are 3 distinct, counter-intuitively named policies that can be defined for automatic calendar processing:
- Book-In Policy Requests
- Users that are defined in the ‘Book-In-Policy’ are allowed to automatically schedule a resource if it available. Resource delegates do not have to approve these requests.
- In-Policy Requests
- Requests from users defined in the ‘In-Policy’ group must be approved by a resource delegate.
- Out-Of-Policy Requests
- Users defined in the ‘Out-Of-Policy’ group have their requests automatically approved unless there is a conflict on the resource calendar. If a conflict exists, the calendar request is forwarded to resource delegates for approval.
To define a list of users in the ‘book-in’ policy use the following command.
Set-MailboxCalendarSettings resource_alias -BookInPolicy 'user1@domain.com','user2@domain.com'
This command will allow all users to use the ‘book-in’ policy.
Set-MailboxCalendarSettings resource_alias -AllBookInPolicy:$True -AllRequestOutOfPolicy:$False -AllRequestInPolicy:$False
To define a list of users that can submit ‘in-policy’ requests use the following command.
Set-MailboxCalendarSettings resource_alias -RequestInPolicy 'user1@domain.com','user2@domain.com'
This command will allow all users to submit ‘out-of-policy’ requests.
Set-MailboxCalendarSettings resource_alias -AllBookInPolicy:$False -AllRequestOutOfPolicy:$False -AllRequestInPolicy:$True
To define a list of users that can submit ‘in-policy’ requests use the following command.
Set-MailboxCalendarSettings resource_alias -RequestOutOfPolicy 'user1@domain.com','user2@domain.com'
This command will allow all users to submit ‘out-of-policy’ requests.
Set-MailboxCalendarSettings resource_alias -AllBookInPolicy:$False -AllRequestOutOfPolicy:$True -AllRequestInPolicy:$False
If you want to get fancy you can use the following command to allow all users to submit in-policy requests while allowing user1 to submit out-of-policy requests and adding the ‘Executive Committee’ distribution group members to the book-in policy.
Set-MailboxCalendarSettings resource_alias -AllRequestInPolicy:$true -AllRequestOutOfPolicy:$False -AllBookInPo
licy:$False -BookInPolicy:'Executive Committee' -RequestOutOfPolicy:'user1@domain.com'
Resource Delegates
The Set-MailboxCalendarSettings cmdlet allows the administrator to define resource delegates without having to manually configure an Outlook profile and navigate the appropriate menus to define delegates. The feature is one of my favorites and very useful for self-service applications. However it has been a bit buggy. Here are the two bugs I have identified and should be fixed in SP1.
- Error message when you try to accept a meeting request on behalf of an Exchange Server 2007 resource mailbox: "Cannot open Calendar folder for user resource_mailbox_name"
http://support.microsoft.com/kb/930865 - When the Set-MailboxCalendarSettings cmdlet is run to re-apply/add delegates for a resource calendar the original delegate's permissions are removed. The delegate is still displayed when running the ‘Get-MailboxCalendarSettings’ cmdlet however if you look at the permissions on the resource calendar, the delegate’s permissions have been removed. To re-grant permissions on the resource calendar you must run a "Set-MailboxCalendarSettings resource_alias -ResourceDelegates:$null" command. Afterwards you can re-grant permissions to the intended user. Until SP1 is released, I would recommend running this command before making any changes to resource delegates.
Resource Calendar Options
In additions to the features offered by the resource booking attendant there are many other calendar customizations that can be defined. Below are a few useful options that we use all the time. A complete list can be found at http://technet.microsoft.com/en-us/library/aa996340.aspx.
- -AddAdditionalResonse and –AdditionalResponse
- Define an additional response text that will accompany any meeting accept/decline/tentative notices.
- -AddOrganizerToSubject
- If set to $True, the calendar attendant will prepend the meeting organizers name to the meeting subject. This is very useful for quickly identifying the meeting organizer while looking at the resource calendar.
- -AddRequestsTenatively
- If set to $true, all meeting requests will be added to the resource calendar and marked as tentative until acted upon by a resource delegate.
- -DeleteAttachments
- If set to $true, attachments will be removed from the meeting information in the resource mailbox.
- -DeleteComments, -DeleteSubject
- See above.
- -DeleteNonCalendarItems
- If set to $true any non-calendar related messages will be deleted.
- -BookingWindowInDays
- Defines a horizon date for meeting scheduling. Also see EnforceSchedulingHorizon.
- -ConflictPercentageAllowed
- If recurring meetings are enabled you can define a conflict percentage to avoid declining a series of meetings because of a single conflict. An allowed percentage of ‘25’ would allow a meeting with 8 occurrences to be accepted as long as no more than 2 conflicts were detected. A separate decline message would be sent to the organizer for the conflicting meeting times.
- -MaximumConflictInstances
- The same as ConflictPercentageAllowed except with a defined static amount of conflicts allowed.
- -MaximumDurationInMinutes
- If you wish to prevent people from scheduling resources for a day, or possibly a few days, you can define this setting to set the maximum meeting duration. Alternatively, if you set the value to ‘0’ meetings of any length will be processed.
- -ProcessExternalMeetingMessages
- If set to $true, meeting requests from external Exchange organizations will be processed.
OWA Management
If you fear the command line like some of my co-workers (you know who you are… Jon) you can manage most of these settings via connecting to the resource mailbox via OWA and editing the ‘Resource Scheduling Options’. You have the ability to manage all of the calendar settings you would from the command line with the exception of defining resource delegates.
To open the resource mailbox via OWA you must define full-mailbox access to the managing user. This can be done from the Exchange Management Shell with the following command.
Add-MailboxPermission resource_alias –User:domain\username –AccessRights:FullAccess
Further Documentation
- Technet Set-MailboxCalendarSettings Documentation
- Microsoft Exchange Server: Calendar Concierge
- Managing Resource Scheduling
- How to Set Resource Booking Policies
- How to Set Scheduling Role Membership
--Nick
Subscribe to:
Posts (Atom)