MicrosoftMicrosoft
@Ismail: You got it! That is essentially the notable change we are currently working on making to the existing order of steps in TechNet. (technet.microsoft.com/.../bb232195(v=EXCHG.80).aspx).
Migrating the mailboxes first keeps automated scheduling capabilities in place via Direct Booking without any downtime for the users in scheduling meetings (aside for the offline moves themselves of course). The script can be leveraged after the moves have
been completed (perhaps even at a later date, but really, why wait!!!) to validate which mailboxes actually have Direct Booking enabled (you may be surprised at what you discover!). This preparatory work can be done without any automated resource scheduling
downtime, and gets you ready for a quick cut over from Direct Booking to Resource Booking Attendant AutoAccept. The script can then be further leveraged to quickly cut over by disabling Direct Booking en-mass, allowing you to immediately continue with converting
said mailboxes from type User to type Room (or Equipment, etc) via the set-Mailbox cmdlet using the -type Room parameter, and finally enabling the AutoAccept automated processing back-end functionality now native to Exchange via the Set-CalendarProcessing
cmdlet using the -AutomatedProcessing AutoAccept parameter (or Set-MailboxCalendarSettings cmdlet if you happen to have Exchange 2007 in your environment).
So, I would suspect your step 2 to leverage the script at least twice as a recommendation - first in read only mode to paint a picture of which mailboxes actually have Direct Booking enabled, and then again (perhaps using an refined input file derived from
the output of the script) to actually remove the three Direct Booking settings.
Note that between your steps 2 and 3, it is still recommended to downgrade the Author permission from the Default role, as outlined in the steps of the above linked TechNet article.
