50 Views and no responses? Eeeeek.

We are migrating from Exchange 2007 to Exchange 2010. Exchange 2003 still exists for sharing Free/Busy info with a resource forest. Exchange 2010 is patched to RU4 (can’t upgrade to SP1 until we have BlackBerry support). When room mailboxes are moved into the Exchange 2010 environment, we've started having problems with the -ProcessExternalMeetingMessages parameter. If the room mailbox is moved back to Exchange 2007, the room behaves as expected. Here’s a summary of the two issues: 1. The –ProcessExternalMeetingMessages parameter appears to be ignored when the room mailbox exists in Exchange 2010. If I have this parameter set to either $true or $false, external meeting requests are accepted (but, no responses are sent to the external meeting organizer). If I move the mailbox back to 2007, –ProcessExternalMeetingMessages works and meeting organizers receive the automated response. 2. We have a limited number of employees that exist in that resource forest. If one of these employees sends a meeting request to the room when it exists in Exchange 2010, the room marks the request as tentative, regardless of the –ProcessExternalMeetingMessages parameter. Here’s what I’ve tried: 1. Compared the mailbox calendar settings (Get-MailboxCalendarSettings in 2k7 to Get-CalendarProcessing in 2010). No settings have changed in the migration. 2. I’ve created a new room mailbox in Exchange 2010 and see the same symptoms 3. Turned up diagnostic logging on the MSExchangeMailboxAssistants > Resource Booking Attendant > Expert – the event log just shows the meeting as being processed. I’ve searched around the web and didn’t see much info on troubleshooting this. I’m thinking this could be addressed in Exchange 2010 SP1, but, MS doesn’t appear to have released the bugs SP1 addresses (like a rollup). Is there anything else I can try to troubleshoot this issue? Thanks for the help.

Here are the calendar setting in Exchange 2010: RunspaceId : e7dc9332-ab18-4017-885a-81a0b217bc87 AutomateProcessing : AutoAccept AllowConflicts : False BookingWindowInDays : 180 MaximumDurationInMinutes : 1440 AllowRecurringMeetings : True EnforceSchedulingHorizon : True ScheduleOnlyDuringWorkHours : False ConflictPercentageAllowed : 50 MaximumConflictInstances : 10 ForwardRequestsToDelegates : False DeleteAttachments : True DeleteComments : True RemovePrivateProperty : True DeleteSubject : True AddOrganizerToSubject : True DeleteNonCalendarItems : True TentativePendingApproval : True EnableResponseDetails : True OrganizerInfo : True ResourceDelegates : {} RequestOutOfPolicy : AllRequestOutOfPolicy : False BookInPolicy : AllBookInPolicy : True RequestInPolicy : AllRequestInPolicy : True AddAdditionalResponse : True AdditionalResponse : Testing in Exchange 2010 RemoveOldMeetingMessages : True AddNewRequestsTentatively : True ProcessExternalMeetingMessages : False RemoveForwardedMeetingNotifications : True Identity : corp.cdw.com/IT/ECT/Room Test

Hi, Does the Exchange 2010 contains the organizer (sender) account in the GAL? If not, you should add it as contact in the GAL. When Resource Mailbox accepting the meeting request from the organizer, Exchange 2010 will match the user in the GAL, it will not process the meeting request and move it to deleted items without sending response since the user is external user. Thanks Allen

The users in the resource forest are listed in the GAL as mail users. I've opened a ticket with CSS and they haven't found a fix just yet.

Hi, OK, if you get the solution from the CSS, please post it here. Thanks Allen

I have the same problem - has anyone found a solution? Is it worth opening a ticket w/ MSoft?John

Anyone found a solution to this? Im in the same boat, but if i check the resource callendar it do actually process the bookings but as tentative bookings and it gets moved to the bin. And no reply is being sent to the "external" user.Best Regards // Tommy Clarke - Please follow me @ Blog and Twitter

We opened a ticket with Microsoft, and the solution involved doing something with our Receive Connectors - it was quite involved. Unfortunately the fellow who worked on it is on vacation this week. When he returns I'll update this thread.John

Any more info, Martin? Having the same problem here!

The problem for us involved a specific group of users whose mail was hosted by an outside company. We explicitly added the IP addresses for that outside host to our receive connectors. That fixed the problem. I don't know how you'd get it to work if the external users booking the rooms were not from defined IP addresses. Sorry for the slow response. John

Thanks John. What receive connector did you add IP ranges to? The default receive connectors, and the ones in my organization, allow for all IP addresses. Did you create custom ones with particular permissions/properties?