How to Restrict Personal Booking Page Creation for Specific Users in Exchange using PowerShell

Personal booking pages are increasingly popular for simplifying scheduling, but organizations often require fine-grained control over who has the ability to create them. This article provides a step-by-step guide on how to restrict personal booking page access to only designated users within your Exchange environment using PowerShell commands.

Understanding Exchange Configuration Precedence:

It's essential to grasp the hierarchy of configurations in Exchange. Settings applied globally using Set-OrganizationConfig serve as defaults. However, settings configured at the individual user level with Set-CASMailbox will always override these global settings for that specific user. This allows administrators to make exceptions and tailor features for individual mailboxes without altering the organization's default configuration.

Targeted Enabling of Personal Booking Pages:

To achieve the goal of allowing only selected users to create personal booking pages, we will exclusively use the Set-CASMailbox cmdlet. This approach ensures precise control over user access without the need to modify or potentially disrupt your global Exchange settings.

Key Parameters for Control:

The control over personal booking page access is managed through specific parameters within the Set-CASMailbox cmdlet related to Exchange Web Services (EWS) and REST access:

  • EwsEnabled: This parameter dictates whether a mailbox can be accessed using Exchange Web Services. Setting it to $true enables all EWS access, $false disables it entirely, and $null means the setting is not explicitly configured at the user level, and the global setting will apply.
  • EwsApplicationAccessPolicy: This parameter defines the policy for which client applications are permitted to access EWS and REST APIs. EnforceAllowList means only applications explicitly listed in the EwsAllowList are permitted. EnforceBlockList means all applications are allowed except those explicitly listed in the EwsBlockList. $null indicates no specific application access policy is configured for the user.
  • EwsAllowList: When EwsEnabled is $true and EwsApplicationAccessPolicy is EnforceAllowList, this parameter is used to specify the list of applications that are allowed to access the mailbox.
  • EwsBlockList: When EwsEnabled is $true and EwsApplicationAccessPolicy is EnforceBlockList, this parameter is used to specify the list of applications that are not allowed to access the mailbox.

Implementing the Configuration with PowerShell:

Here is the PowerShell script to implement the desired configuration, allowing only a defined list of users to create personal booking pages:

# Define the list of users who should be allowed to create booking pages
$allowedUsers = @("user1@example.com", "user2@example.com", "user3@example.com")

# Get all user mailboxes (excluding shared, etc.)
$allUsers = Get-Mailbox -RecipientTypeDetails UserMailbox | Select-Object -ExpandProperty PrimarySmtpAddress

foreach ($user in $allUsers) {
    # Ensure EWS is enabled and clear any existing policy for all users initially
    Set-CASMailbox -Identity $user -EwsEnabled $true -EwsApplicationAccessPolicy $null

    if ($allowedUsers -contains $user) {
        # Add the booking page application to the allow list for allowed users
        Set-CASMailbox -Identity $user -EwsAllowList @{Add = "MicrosoftOWSPersonalBookings"}
        # Ensure it's not in the block list (in case of previous configurations)
        Set-CASMailbox -Identity $user -EwsBlockList @{Remove = "MicrosoftOWSPersonalBookings"}
    } else {
        # Add the booking page application to the block list for other users
        Set-CASMailbox -Identity $user -EwsBlockList @{Add = "MicrosoftOWSPersonalBookings"}
        # Ensure it's not in the allow list (in case of previous configurations)
         Set-CASMailbox -Identity $user -EwsAllowList @{Remove = "MicrosoftOWSPersonalBookings"}
    }
}

Explanation of the PowerShell Script:

  1. Defining Allowed Users: The script begins by creating an array, $allowedUsers, which holds the email addresses of the individuals who should have the ability to create personal booking pages.
  2. Retrieving All Users: It then fetches the primary SMTP addresses of all mailboxes categorized as UserMailbox. This ensures the script processes all standard user accounts.
  3. Initial EWS Configuration Loop: The first loop iterates through every retrieved user. Inside this loop, Set-CASMailbox is used to ensure that EwsEnabled is set to $true (as booking pages rely on EWS) and that any existing EwsApplicationAccessPolicy at the user level is cleared ($null). This provides a clean slate for applying our specific allow/block rules for the booking page application.
  4. Conditional Allow/Block List Configuration Loop: The second loop is where the core logic resides. For each user, it checks if their email address is present in the $allowedUsers array.
    • If the user is in the allowed list: The script uses Set-CASMailbox -EwsAllowList @{Add = "MicrosoftOWSPersonalBookings"} to add the specific application identifier for personal bookings ("MicrosoftOWSPersonalBookings") to that user's EWS allow list. It also explicitly removes it from the block list to avoid conflicts.
    • If the user is NOT in the allowed list: The script uses Set-CASMailbox -EwsBlockList @{Add = "MicrosoftOWSPersonalBookings"} to add the personal bookings application identifier to that user's EWS block list, preventing them from using the feature. It also explicitly removes it from the allow list.

Conclusion:

By following these steps and utilizing the provided PowerShell script, Exchange administrators can effectively restrict the creation of personal booking pages to a specified group of users. This granular control enhances organizational security and ensures that powerful scheduling tools are available to the individuals who need them most, contributing to a more organized and productive environment. 

Comments

Post a Comment

Popular posts from this blog

Unveiling Primary Mailbox Statistics

Keep your Microsoft Exchange environment running smoothly with these simple PowerShell commands. Primary Mailbox Insights Want to know how much space primary mailboxes are using? This single command gives you a clear picture of storage status, item count, and total size: PowerShell Command Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select DisplayName, StorageLimitStatus , @{ Name = " TotalItemSize (MB) "; Expression = { [math]::Round(($_.TotalItemSize.ToString().Split("(")[1].Split(" ")[0].Replace(",", "") / 1MB), 2) }}, ItemCount | Sort " TotalItemSize (MB) " -Descending | Export-CSV " C:\temp\All Mailboxes.csv " -NoTypeInformation This command does all the heavy lifting: It fetches all user mailboxes fast. It gathers essential stats like size and item count. It converts sizes to MB for easy reading. It sorts mailboxes from largest to sma...
Read more

Manage DL Members in OWA Without Allowing DL Creation – A Practical Solution

Today, I'd like to share a real-world workaround that solves a common issue in Microsoft 365: giving users the ability to manage Distribution List (DL) members through Outlook on the Web (OWA) without giving them permission to create or delete DLs. This is a frequent request for organizations focused on strict governance and efficient delegation. The Challenge A client recently encountered a problem where a user was unable to manage Distribution Group (DG) members via OWA. After some investigation, we discovered that the MyDistributionGroups role was not included in their role assignment policy. While enabling this role would solve the immediate issue, it comes with a significant drawback: it also grants the user the ability to create and delete DLs. For organizations with strict governance policies or those that prefer centralized DL creation, this isn't an ideal scenario. The Goal Our objective was clear: Allow users to manage existing Dist...
Read more

PowerShell Basics for Office 365 Administration (Episode 3)

At its core, PowerShell is designed around the concept of objects. Unlike traditional command-line interfaces that often work with text streams, PowerShell processes structured data in the form of objects. Understanding how objects, properties, and methods function, how variables store and manage this data, and how the pipeline enables seamless command chaining is fundamental to effective Office 365 administration. Understanding Objects, Properties, and Methods In the world of PowerShell, virtually everything you interact with is an object. An object is a structured data entity representing specific items, whether it's a user account, a mailbox, a group, or a system service. These objects possess two primary characteristics: Properties: These are the attributes or characteristics that describe the object. For example, a mailbox object might have properties like DisplayName , EmailAddresses , or RecipientTypeDetails . Methods: These represent the actions or functions that the ob...
Read more