Use Exchange Web Services and PowerShell to Discover and Remove Direct Booking Settings
Published May 09 2013 05:45 PM 36.7K Views

 

Update 7/15/2013: we have made a few updates to the below blog post to adjust the instructions for the release of the version 2 of the script.

Prior to Exchange 2007, there were two primary methods of implementing automated resource scheduling – Direct Booking and the AutoAccept Agent (a store event sink released as a web download for Exchange 2003). In Exchange 2007, we changed how automated resource scheduling is implemented. The AutoAccept Agent is no longer supported, and the Direct Booking method, technically an Outlook function, has been replaced with server-side calendar booking function called the Resource Booking Attendant.

Note: There are various terms associated with this new Resource Booking function, such as: Calendar Processing, Automatic Resource Booking, Calendar Attendant Processing, Automated Processing and Resource Booking Assistant. We will be using the “Resource Booking Attendant” nomenclature for this article.

While the Direct Booking method for resource scheduling can indeed work on Exchange Server 2007/2010/2013, we strongly recommend that you disable Direct Booking for resource mailboxes and use the Resource Booking Attendant instead. Specifically, we are referring to the “AutoAccept” Automated Processing feature of the Resource Booking Attendant, which can be enabled for a mailbox after it has been migrated to Exchange 2007 or later and upgraded to a Resource Mailbox.

Note: The published resource mailbox upgrade guidance on TechNet specifies to disable Direct Booking in the resource mailbox while still on Exchange 2003, move the mailbox, and then enable the AutoAccept functionality via the Resource Booking Attendant. This order of steps can introduce an unnecessary amount of time where the resource mailbox may be without automated scheduling capabilities.

We are currently working to update that guidance to reflect moving the mailbox first, and only then proceed with disabling the Direct Booking functionality, after which the AutoAccept functionality via the Resource Booking Attendant can be immediately enabled. This will shorten the duration where the mailbox is without automated resource scheduling capabilities.

This conversion process to resource mailboxes utilizing the Resource Booking Attendant is sometimes an honest oversight or even deliberately ignored when migrating away from Exchange 2003 due to Direct Booking’s ability to continue to work with newer versions of Exchange, even Exchange Online. This will often result in resource mailboxes (or even user mailboxes!) with Direct Booking functionality remaining in place long after Exchange 2003 is ancient history in the environment.

Why not just leave Direct Booking enabled?

There are issues that can arise from leaving Direct Booking enabled, from simple administrative burden scenarios all the way to major calendaring issues. Additionally, Resource Booking Attendant offers advantages over Direct Booking functionality:

  1. Direct Booking capabilities, technically an Outlook function, has been deprecated from the product as of Outlook 2013. It was already on the deprecation list in Outlook 2010 and required a registry modification to reintroduce the functionality.
  2. Direct Booking and Resource Booking Attendant are conflicting technologies, and if simultaneously enabled, unexpected behavior in calendar processing and item consistency can occur.
  3. Outlook Web App (as well as any non-MAPI clients, like Exchange ActiveSync (EAS) devices) cannot use Direct Booking for automated resource scheduling. This is especially relevant for Outlook Web App-only environments where the users do not have Microsoft Outlook as a mail client.
  4. The Resource Booking Attendant AutoAccept functionality is a server-side solution, eliminating the need for client-side logic in order to automatically process meeting requests.

How do I check which mailboxes have Direct Booking Enabled?

How does one validate if Direct Booking settings are enabled on mailboxes in the organization, especially if mailboxes had previously been hosted on Exchange 2003?

Screenshot: Resource Scheduling properties
Figure 1: Checking Direct Booking settings in Microsoft Outlook 2010

Unfortunately, the manual steps involve assigning permissions to all mailboxes, creating MAPI profiles for each mailbox, logging into each mailbox, checking Tools > Options > Calendar > Resource Scheduling, note which of the three Direct Booking checkboxes are checked, click OK/Cancel a few times, log out of mailbox. Whew! That can be a major undertaking even for a small to midsize company that has more than a handful of mailboxes! Having staff perform this type of activity manually can be a costly and tedious endeavor. Once you have discovered which mailboxes have the Direct Booking settings enabled, you would then have to repeat this entire process to disable these settings unless you removed them at the time of discovery.

Having an automated method to discover, track, and even disable Direct Booking settings would be nice right?

Look no further, we have the solution for you!

Using Exchange Web Services (EWS) and PowerShell, we can automate the discovery of Direct Booking settings that are enabled, track the results, and even disable them! We wrote Remove-DirectBooking.ps1, a sample script, to do exactly that and even more to aid in automating this manual effort. The script is attached to this blog post.

After you've downloaded it, rename the file and remove the .txt extension.

IMPORTANT:  The previously uploaded script had the last line truncated to Stop-Tran (instead of Stop-Transcript). We've uploaded an updated version to TechNet Gallery. If you downloaded the previous version of the script, please download the updated version. Alternatively, you can open the previously downloaded version in Notepad or other text editor and correct the last line to Stop-Transcript.

Let’s break down the major tasks the PowerShell script does:

  1. Uses EWS Application Impersonation to tap into a mailbox (or set of mailboxes) and read the three MAPI properties where the Direct Booking settings are stored. It does this by accessing the localfreebusy item sitting in the NON_IPM_SUBTREE\FreeBusy Data folder, which resides in the root of the Information Store in the mailbox. The three MAPI properties and their equivalent Outlook settings the script looks at are:

    • 0x686d Automatically accept meeting requests and remove canceled meetings
    • 0x686f Automatically decline meeting requests that conflict with an existing appointment or meeting
    • 0x686e Automatically decline recurring meeting requests

    These three properties contain Boolean values mirroring the Resource Scheduling checkboxes found in Outlook (see Figure 1 above).

  2. For each mailbox processed, the script attempts to locate the corresponding free/busy message stored in the ‘Schedule+ Free/Busy’ system Public Folder representing the user.  This item must be updated just like the user’s local mailbox item – the two items must be consistent in their settings. We need to do this because Outlook only considers the settings in the Public Folder free/busy item when a user attempts to Direct Book a resource.  Therefore, it is critical that the script checks for the Public Folder item’s existence and its settings are in sync with the localfreebusy item stored in the mailbox itself.
  3. For mailboxes where Direct Booking settings were detected, it checks for conflicts by determining if the mailbox also has Resource Booking Attendant enabled with AutomateProcessing set to AutoAccept.
  4. Optionally, disables any enabled Direct Booking settings encountered.

    Note: It is important to understand that by default the script runs in a read-only mode. Additional command line switches are available to run the script to disable Direct Booking settings.

  5. Writes a detailed runtime processing log to console and log file.
  6. Creates a simple output text file containing a list of mailboxes that can be later leveraged as an input file to feed the script for disabling the Direct Booking functionality.
  7. Creates a CSV file containing statistics of the list of mailboxes processed with detailed information, such as what was discovered, any errors encountered, and optionally what was disabled. This is useful for performing analysis in the discovery phase and can also be used as another source to create an input file to feed into the script for disabling the Direct Booking functionality.

Example Scenarios

Here are a couple of example scenarios that illustrate how to use the script to discover and remove enabled Direct Booking settings.

Scenario 1

You've recently migrated from Exchange 2003 to Exchange 2010 and would like to disable Direct Booking for your company’s conference room mailboxes as well as any user mailboxes that may have Direct Booking settings enabled. The administrator’s logged in account has Application Impersonation rights and the View-Only Recipients RBAC role assigned.

  1. On a machine that has the Exchange management tools & the Exchange Web Services API 1.2 or greater installed, open the Exchange Management Shell, navigate to the folder containing the script, and run the script using the following syntax:

    .\Remove-DirectBooking.ps1 –identity * -UseDefaultCredentials

  2. The script will process all mailboxes in the organization with detailed logging sent to the shell on the console. Note, depending the number of mailboxes in the org, this may take some time to complete
  3. When the script completes, open the Remove-DirectBooking_<timestamp>.txt file in Notepad, which will contain list of mailboxes that have Direct Booking enabled:

    Screnshot: The Remove-Directbooking log generated by the script
    Figure 2: Output file containing list of mailboxes with Direct Booking enabled

  4. After reviewing the list, rerun the script with the InputFile parameter and the RemoveDirectBookingswitch:

    .\Remove-DirectBooking.ps1 –InputFile ‘.\Remove-DirectBooking_<timestamp>.txt’ –UseDefaultCredentials -RemoveDirectBooking

  5. The script will process all the mailboxes listed in the input file with detailed logging sent to the shell on the console. Because you specified the RemoveDirectBooking switch, it does not run in read-only mode and disables all currently enabled Direct Booking settings encountered.
  6. When the script completes, you can check the status of the removal operation by checking the Remove-DirectBooking_<timestamp>.csv file. A column called Direct Booking Removed? will record if the removal was successful. You can also check the runtime processing log file RemoveDirectBooking_<timestamp>.logas well.

    image
    Figure 3: Reviewing runtime log file in Excel

Note The Direct Booking Removed? column now shows Yes where applicable, but the three Direct Booking settings colum ns still show their various values as “Yes”; this is because we record those three values pre-removal. If you were to run the script again in read-only mode against the same input file, those columns would reflect a value of N/A since there would no longer be any Direct Booking settings enabled. The Resource Room?, AutoAccept Enabled?, and Conflict Detected all have a value of N/A regardless because they are not relevant when disabling the Direct Booking settings.

Scenario 2

You're an administrator who's new to an organization. You know that they migrated from Exchange 2003 to Exchange 2007 in the distant past and are currently in the process of implementing Exchange 2010, having already migrated some users to Exchange 2010. You have no idea what resources mailboxes or even user mailboxes may be using Direct Booking and would like to discover who has what Direct Booking settings enabled. You would then like to selectively choose which mailboxes to pilot for Direct Booking removal before taking action on the majority of found mailboxes.

Here's how you would accomplish this using the Remove-DirectBooking.ps1 script:

  1. Obtain a service account that has Application Impersonation rights for all mailboxes in the org.
  2. Ensure service account has at least Exchange View-Only Administrator role (2007) and at least have an RBAC Role Assignment of View Only Recipients (2010/2013).
  3. On a machine that has the Exchange management tools & the Exchange Web Services API 1.2 or greater installed, preferably an Exchange 2010 server, open the Exchange Management Shell, navigate to the folder containing the script, and run the script using the following syntax:

    .\Remove-DirectBooking.ps1 –Identity *

  4. The script will prompt you for the domain credentials of the account you wish to use because no credentials were specified. Enter the service account’s credentials.
  5. The script will process all mailboxes in the organization with detailed logging sent to the shell on the console. Note, depending the number of mailboxes in the org, this may take some time to complete.
  6. When the script completes, open the Remove-DirectBooking_<timestamp>.csv in Excel, which will looks something like:

    image

    Figure 4: Reviewing the Remove-DirectBooking_<timestamp>.csv in Excel

  7. Filter or sort the table by the Direct Booking Enabled? column. This will provide a list that can be scrutinized to determine which mailboxes are to be piloted with Direct Booking removal, such as those that have conflicts with already having the Resource Booking Attendant’s Automated Processing set to AutoAccept (which you can also filter on using the AutoAccept Enabled? column).
  8. Once the list has been reviewed and the targeted mailboxes isolated, simply copy their email addresses into a text file (one address per line), save the text file, and use it as the input source for the running the script to disable the Direct Booking settings:

    .\Remove-DirectBooking.ps1 –InputFile ‘.\’ -RemoveDirectBooking

  9. As before, the script will prompt you for the domain credentials of the account you wish to use. Enter the service account’s credentials.
  10. The script will process all the mailboxes listed in the input file with detailed logging sent to the shell on the console. It will disable all enabled Direct Booking settings encountered.
  11. Use the same validation steps at the end of the previous example to verify the removal was successful.

Script Options and Caveats

Please see the script’s help section (via “get-help .\remove-DirectBooking.ps1 -full”) for full information on all the available parameters. Here are some additional options that may be useful in certain scenarios:

  1. EWSURL switch parameter. By default, the script will attempt to retrieve the EWS URL for each mailbox via AutoDiscover. This is preferred, especially in complex multi-datacenter or hybrid Exchange Online/On-premises environments where different EWS URLs may be in play for any given mailbox depending on where it resides in the org. However, there may be times where one would want to supply an EWS URL manually, such as when AutoDiscover is having “issues”, or the response time for AutoDiscover requests is introducing delays in overall script execution (think very large quantity of number of mailbox identities to churn through) and the EWS URL is the same across the org, etc. In these situations, one can use the EWSURL parameter to feed the script a static EWS URL.
  2. UseDefaultCredentials If the current user is the service account or perhaps simply has both the Impersonation and the necessary Exchange Admin rights per the script’s requirements and they don’t wish to be prompted to type in a credential (another great example is scheduling the script to run as a job for instance), you can use the UseDefaultCredentials to run the script under that security context.
  3. RemoveDirectBooking By default, the script runs in read-only mode. In order to make changes and disable Direct Booking settings on the mailbox, you mus specify the RemoveDirectBooking switch.

The script does have several prerequisites and caveats to ensure proper operation and meaningful results:

  1. Application Impersonation rights and minimum Exchange Admin rights must be used
  2. Exchange Web Services Managed API 1.2 or later must be installed on the machine running the script
  3. Exchange management tools must be installed on the machine running the script
  4. Script must be executed from within the Exchange Management Shell
  5. The Shell ses sion must have the appropriate execution policy to allow the script to be executed (by default, you can't execute unsigned scripts).
  6. AutoDiscover must be configured correctly (unless the EWS URL is entered manually)
  7. Exchange 2003-based mailboxes cannot be targeted due to lack of EWS capabilities
  8. In an Exchange 2010/2013 environment that also has Exchange 2007 mailboxes present, the script should be executed from a machine running Exchange 2010/2013 management tools due to changes in the cmdlets in those versions
  9. Due to limitations in the EWS architecture, the Schedule+ Free/Busy System Folder subfolders must contain a replica on each version of Exchange that users are being processed for; additionally, the user's Exchange mailbox database 'Default public folder database' property must be set to a Public Folder database that is on the same version of Exchange as the mailbox database.

Summary

The discovery and removal of Direct Booking settings can be a tedious and costly process to perform manually, but you can avoid and automate it using current functions and features via PowerShell and EWS in Microsoft Exchange Server 2007, 2010, & 2013. With careful use, the Remove-DirectBooking.ps1 script can be a valuable tool to aid Exchange administrators in maintaining automated resource scheduling capabilities in their Microsoft Exchange environments.

Your feedback and comments are welcome.

Thank you to Brian Day and Nino Bilic for their guidance in content review, and to our customers (you know who you are) for piloting the script.

Seth Brandes & Dan Smith

37 Comments
Not applicable

Hello Gents,

I would like to thanks to the entire team who has been involved with this kind of simple solution compare to the previous one.

I would like to know from you guys whether the following approach can be considered best approach if we are following migration of resource mailbox from Exchange 2003 to Exchange 2010 which has direct booking enabled.

1) Migrate the resource mailbox from exchange 2003 to exchange 2010

2) Execute remove-directbooking.ps1 script on migrated resource mailboxes

3) Convert the resource mailbox to room or equipment

4) Enable AutoAccept.

Not applicable

@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.

Not applicable

Thanks for this script that will help a lot for migrating these ressource mailboxes.

Just a remark, I never succeeded in having direct booking working on E2K10 after migrating from E2K3( without converting the ressource mailbox, just moving it) : sometimes it works, sometimes no.

You wrote that "While the Direct Booking method for resource scheduling can indeed work on Exchange Server 2007/2010/2013" but are there any requirements to get this working and is it a supported scenario?

Another remark, I've noticed that direct booking from users migrated to E2K10 on a ressource mailbox still on E2K3 was very slow. Have you ever heard of this kind of issue?

Not applicable

Hi,

When I run .Remove-DirectBooking.ps1 –identity * -UseDefaultCredentials

for each account I have got "MAPI attributes not found."

Should I fix it somehow?

Not applicable

Maybe it's worth mentioning that for the last couple of years we have also been using this:

blogs.msdn.com/.../setaa-tweak-auto-accept-settings-across-mailboxes.aspx.

Thanks

Not applicable

The last line of the script (line 492) has the cmdlet Stop-Tran (rather then Stop-Transcript) which errors out.

Not applicable

@Mike Do you have impersonation setup for your account? Because if you don't it will not work, because the account used needs to have full access to all mailboxes.

Not applicable

@Mike:

"MAPI attributes not found"  isn't necessarily an error if you aren't getting other errors (such as a bind/login error). It simply means that the attributes are not present on the mailbox, which means Direct Booking has never been set on it.  The properties don't even exist until the first time you enable the Direct Booking settings.

Not applicable

@Kris: Thanks for the heads up, it looks like that last line got truncated; we are working on correcting that.

Not applicable

@Pierrejean: Thank you, we hope it helps in your migration efforts!

In regards to the spotty behavior that you observed, my only immediate thought is perhaps some of the users were running Outlook 2010 and did not have the reg hack required to reintroduce the Direct Booking functionality?  There are no other requirements that I am aware that deliberately need to be followed - just don't have both Direct Booking and Resource Booking Attendant mechanisms in play simultaneously.

I have not heard of specific issues with slowness in having an Exchange 2007+ based mailbox performing Direct Booking lookups against an Exchange 2003 based resource mailbox.

Not applicable

@Andrei G: You are correct--the SetAA tool has been available for some time, has the ability to modify Direct Booking settings and can be incorporated into a script if you so choose.  While Stephen's SetAA script has been wonderful for making direct booking setting changes over the years, we wanted to create a solution that incorporates detection and reporting capabilities, as well as the ability to make intelligent decisions about how to remediate conflicting settings. The Remove-DirectBooking.ps1 script provides all of these features to ensure that you are able to discover all the mailboxes in the environment that have Direct Booking enabled, as well as ensuring that existing Room or Equipment mailboxes that have AutoAccept enabled do NOT also have Direct Booking enabled.  Also, since it uses EWS and AutoDiscover, the new script is optimal for multi-site and hybrid on-premises/Exchange Online deployments.

Not applicable

Thank you Seth and Dan, great script.

Not applicable

Hello,

Nice script, but...

When I disabled the Direct Booking using this script I have now some users calling me that when they book the meeting, they got response:

"mailbox name" declined your meeting because it is recurring. You must book each meeting separately with this resource.

I have checked out, and this happens when user uses Outlook 2007 and Outlook 2010. When I am booking the meeting on the same resource using Outlook 2013 it works OK.

Checked the following:

Get-CalendarProcessing "mailbox name"|fl AutomateProcessing

AutomateProcessing                  : AutoAccept

Get-CalendarProcessing "mailbox name"|fl *policy

RequestOutOfPolicy    : {}

AllRequestOutOfPolicy : False

BookInPolicy          : {}

AllBookInPolicy       : True

RequestInPolicy       : {}

AllRequestInPolicy    : False

Can you tell what else to do to make it working proper?

Not applicable

hello Seth & Dan,

Executed the script however I am getting this following error "mailbox name" declined your meeting because it is recurring. You must book each meeting separately with this resource

Outlook Version 2007,

Not applicable

I am taking this Opportunity to thanks for all the support engineers.

I was doing the same modification after migrating the mailbox from 2003 to 2010 now this script help us to reduce administive effect.

Not applicable

@Josh & Ismail, it would be helpful if you provide the Exchange Server version in use. Have you already confirmed if AllowRecurringMeetings is set to $True or $False in your calendar processing settings?

Not applicable

@Brian. I am running Exch 2010 S2 Rollup 3.

Checked on all meeting rooms - AllowRecurringMeetings : True

Just to make it clear - all calling users did not want to create recuring meetings but only on time meeting next week.

Any ideas?

Not applicable

@Josh , @Ismail: Thank you for bringing this to our attention.  We have identified a possible source that may be causing your issue, and we are currently working to validate it.

Not applicable

@Seth, should I bring back direct booking on all my resources temporary?

If yes, can you give me a tip what to change in the script to revert the changes?

Not applicable

@Josh:

We do not have an ETA yet on an update to address the issue but are actively working on it and will post when it has been addressed.

In the meantime you can try the following if you wish to revert:

*Revert the Resource Booking Attendant settings

1. flip the Automated Processing back to AutoUpdate on the rooms (set-calendarprocessing [or set-mailboxcalendarsettings] <mailboxid> -AutomatedProcessing AutoUpdate)

2. flip the rooms back to type User (set-mailbox <mailboxid> -type:Regular)

*Edit the script

3. remove the extended property definitions that you do NOT want to re-enable. (lines 274-276)

4. change the logic on line 347 from -eq $true to -eq $false. Line should read: if ($property.value -eq $false)

5. change the logic on line 355 from $false to $true. Line should read: $freebusyItem.SetExtendedProperty($property.propertydefinition,$true)

6. Save the script with a different file name (you'll still need the original script)

*Run the updated script in change mode (only against the rooms you need to target!), ignore the language of the output as it will be all wrong.

*Re-run the original (unmodified) script in read-only mode to validate the changes took affect and Direct Booking is re-enabled.

Not applicable

@Seth: intead of lines 274-276, you need to remove the parameter which you do not want to change from line 279 i.e: $PropSet = new-object Microsoft.Exchange.WebServices.Data.PropertySet($PR_SCHDINFO_AUTO_ACCEPT_APPTS,$PR_SCHDINFO_DISALLOW_OVERLAPPING_APPTS)  

Than it works. Thanks for revert procedure and waiting for the fix of the issue.

Not applicable

@Mike: Ah, that's right, thanks for the correction!  We'll let y'all know as soon as we have an update to share.  We are actively working on it.

Not applicable

Executed in read-only for 17,596 mailboxes.

Execution completed. Runtime: 11 hours, 21 minutes, 53 seconds.

Not applicable

@Kris: You are averaging around 2.3 mbx/sec.  If you have a consistent EWS URL, you can try running the script (read-only of course) feeding it the URL for EWS using the -EWSURL switch.  This will cut out the AutoDiscover lookup for each mailbox and I would surmise would result in a faster runtime.  As we pointed out in the article this should only be recommended for use in certain circumstances, like a consistent EWS URL, etc.

Another factor to check on would be EWS throttling depending on what Exchange version, SP, and RU you are running.

Not applicable

Hi,

I have a question regarding the first screenshot in this post (Checking Direct Booking settings in Microsoft Outlook 2010): In your screenshot all settings in the dialog box are disabled. It is therefore not possible to enable any of those settings using Outlook. I've seen this behaviour before in some Exchange environments and was wondering what setting in Exchange causes all checkboxes in that dialog box to be disabled.

Not applicable

@CountryKING™:  If the checkboxes are unavailable, it most likely due to either 1) there are no Public Folder databases present in the Organization or 2) Public Folders are unavailable for some reason (dismounted, network issues, etc).  Direct Booking relies on the Schedule+ Free/Busy system folders to function.

Not applicable

Thanks, much appreciated this effort!!!

This is definitely a very valuable and useful tool, to ease and automate a task that otherwise would be time consuming!

Not applicable

After running script against 270 mailboxes in our environment which had direct booking enabled. We had same issue mentioned by Josh i.e. Outlook 2007 users getting prompt to use single instance meeting (even though meetings were single occurrence) AND Outlook still trying to use direct booking.

As workaround, we used below registry on user machine to fix this, since it was only impacting Outlook 2007 users. (Direct booking is disabled by default in Outlook 2010 to my knowledge and Outlook 2013 doesn't supports it altogether)

[HKEY_CURRENT_USERSoftwareMicrosoftOffice12.0OutlookOptionsCalendar]

"EnableDirectBooking"=dword:00000000

Not sure, reverting back 270 mailboxes and then in future reverting again to final state sounded complicated and could've confused users, registry still looked easier, unless it'll impact users in other ways?

Not applicable

Is it proper way to workarround the issue as AJKL did with the registry? [HKEY_CURRENT_USERSoftwareMicrosoftOffice12.0OutlookOptionsCalendar]

"EnableDirectBooking"=dword:00000000

Not applicable

@AJKL and Mike:  Disabling the Outlook Direct Booking feature via GPO is certainly a tactical option to work around this issue, since Outlook will never try to Direct Book a resource at that point. While this solution is feasible it should be used with caution. It may be difficult to ensure that the policy gets applied to all clients, especially any non-domain joined clients that may be connecting to Exchange. We will be releasing a revised script very soon that will address the root cause of this issue and we strongly recommend re-running the script with the -RemoveDirectBooking switch to rectify this issue permanently even if the outlook registry modification method has already been used.  This will ensure the settings get permanently disabled.

Not applicable

Thanks David, will sure do.

The GPO/Registry was/is just intentional temporary workaround or temporary relief for users who were having issue. As soon as script is updated, we'll retire that policy as well accordingly.

Permanent resolution is still to disable the direct booking attributes on conference rooms as suggested.

Not applicable

Big thanks to you all! This is so big help for us!

Not applicable

@Seth Brandes

Did you find a resolution for the issue which Josh has raised?

11 May 2013 8:57 PM

#

Not applicable

@Mike:  Yes, we have an update to the script that will address the issue.  It is in the final phase of testing and we will be posting it shortly with additional information.

Not applicable

I have this exact need migrating previous exch2k3 resources to exch2k10.

However, my clients are still on outlook 2k7 and the bug regarding recurring meeting warning bothers me.

any news on the updated version of the script?

Not applicable

@stoufsot:  Look for an updated version of the script and an update to this blog post early next week.

Not applicable

We updated the article as well as the script to address the scenario and error message reported.  Due to the nuances of the scenario, we expounded on the details of why this scenario occurs and what was changed in the script in a new article:

blogs.technet.com/.../a-significant-update-to-remove-directbooking-script-is-now-available.aspx

We appreciate all the feedback, keep it coming!

Version history
Last update:
‎Apr 28 2020 02:00 PM
Updated by: