Microsoft Bookings is slowly getting more and more popular, boosted by a strong marketing campaign, but also a set of useful features Microsoft has rolled out over the past year. Many of those features focused on protecting both yours and your customer’s privacy. Tony covered most of the settings over at the Office 365 for IT Pros blog a while back, including the corresponding properties as exposed via the Get-OrganizationConfig cmdlet. Since then, few more settings have become available, as evident from the screenshot below:
But the biggest feature we got is yet to actually make it to the Microsoft 365 Admin Center UI, and for the time being is only controllable via PowerShell. I’m talking about the Naming policy feature, with Roadmap ID of 88991, which is now generally available. As we will see in this article, the feature works very similar to the Distribution group naming policy feature and in fact even borrows some of its properties.
Let’s start by introducing the corresponding properties. As mentioned above, you will need the good old Get-OrganizationConfig cmdlet and the relevant permissions to invoke it. The properties controlling the Booking naming policy settings include:
- BookingsNamingPolicyEnabled, with default value of False, controls whether the Bookings naming policy is enabled in the organization.
- BookingsBlockedWordsEnabled specifies whether to enforce a blocklist of words not allowed in the organization. Default value is False.
- BookingsNamingPolicyPrefixEnabled allows you to enforce a prefix as part of the Bookings naming policy. The default value is False.
- BookingsNamingPolicyPrefix specifies the value to be used as the prefix. Default value is null/empty string. Make sure to include some sort of a delimiter if you plan to use this setting, such as a dash, or even a space character. Otherwise, the Prefix value will be merged with the name the user provides (see example below).
- BookingsNamingPolicySuffixEnabled is similar to the above, but instead of prefix enforces a suffix to be added as part of the Booking name. Default value is also False.
- BookingsNamingPolicySuffix specifies the suffix value. Default value here is null/empty string.
- DistributionGroupNameBlockedWordsList controls the actual list of words not allowed in the organization. As the name suggests, this setting is not specific to the Booking naming policy and is shared with the Distribution group naming policy controls. The default value here is null/empty list.
To update the Booking naming policies controls within your tenant, use the Set-OrganizationConfig cmdlet. The example below makes sure the naming policy is enforced and will stamp a string to the begging of the name users provide as part of the creation process. We’re also specifying that a list of blocked words should be enforced, however as mentioned above the property controlling this list is “borrowed” from the distribution group naming policy controls. You can of course specify them all in a single cmdlet, the below is just for illustrative purposes.
Set-OrganizationConfig -BookingsBlockedWordsEnabled $true -BookingsNamingPolicyEnabled $true -BookingsNamingPolicyPrefix "Booking" -BookingsNamingPolicyPrefixEnabled $true
Set-OrganizationConfig -DistributionGroupNameBlockedWordsList @{add="CEO"}
After making the changes, we can verify the current Booking naming policy controls:
Get-OrganizationConfig | select BookingsNaming*,DistributionGroupNameBlockedWordsList
BookingsNamingPolicyEnabled : True
BookingsBlockedWordsEnabled : True
BookingsNamingPolicyPrefixEnabled : True
BookingsNamingPolicyPrefix : Booking
BookingsNamingPolicySuffixEnabled : False
BookingsNamingPolicySuffix :
DistributionGroupNameBlockedWordsList : {CEO}
And with that, our naming policy is created and will start working after a synchronization on the backend. To see how the policy is enforced, we can login as a regular user to the Bookings homepage and hit the Create new calendar button to provision a new Booking (if allowed by policy of course). At that stage, we will be presented with a small infotip next to the Name control, clicking which will inform you that a naming policy is in place and will actually reflect the enforced controls. In our scenario, it tells the that “Your admin has added a prefix to the calendar name“, and the value of the prefix is also shown next to the Name field:
Apart from this point, the process remains the same and after you go over the remaining steps of the wizard, a new Booking mailbox will be provisioned. In our case, this will result in a rather unfortunate name for it though, as we neglected adding a delimiter to our policy. Thus the “Booking” prefix value will be glued together with the name we provided, resulting in:
Get-Mailbox -RecipientTypeDetails Sched | select Name,DisplayName,Alias,PrimarySmtpAddress BookingTest naming policy_16d92ebb85 BookingTest naming policy BookingTestnamingpolicy BookingTestnamingpolicy@domain.com
As shown in the output above, the prefix value is also stamped on the Primary SMTP Address of the Bookings mailbox, which is something you need to be wary of. In case the prefix/suffix value you’ve chosen contains an unacceptable character, a “safe” value for the Primary SMTP will be generated, stripping any disallowed characters (and spaces).
As another example, let’s take a look at what happens when we try to provide a name that matches a blocked word. In our naming policy, we opted to block the “CEO” word, so when trying to create a new Booking calendar that features “CEO” as the name, we’re greeted with an error message. Unlike the infotip, the message presented here is not very descriptive, but the important thing is of course the end result – the user is prevented from creating a new Booking that uses the blocked word value. Note that the match is on a per-word basis!
Lastly, do note that the Booking naming policy restrictions also apply to admin users when they create a new Booking (mailbox) from a client application such as OWA, but also when using the admin tools such as the New-SchedulingMailbox cmdlet. This is a change in behavior introduced a while back that also affects the distribution group policy. Unlike the distribution group scenario though, admins have no way of overriding the policy (no- IgnoreNamingPolicy switch). So in case you need to create a Booking with a name that goes against the policy, your only option seems to be to temporary disable the policy controls.