Prevent Users from Creating O365 Groups

Office 365 Groups are a powerful collaboration tool within Office 365, and by default can be created by all users. Several objects are created when you create a group, including a shared inbox, group calendar, and a SharePoint site. This, along with the fact that groups can contain users external to your organization, may lead to some concerns about how groups will be managed. Some organizations may prefer to prevent users from being able to create Office 365 groups.

I have seen similar posts that indicate you can just set the GroupCreationEnabled flag to $False in the Outlook Web App policy. And while this will work to some extent, it’s only part of the picture. You have remember that Office 365 Groups are used with several O365 services. SharePoint, Planner, and Teams to name a few. The method of disabling groups mentioned above, will only disable group creation for Exchange Online. To cover the rest of the tenant, we’ll need to use PowerShell to correctly configure the restriction.

We will need to create a security group to contain the users that we want to allow to create Office 365 Groups. Remember, that if you are running a hybrid environment you will want to create and manage this group from on-premises AD and allow it to replicate to O365 before continuing. Once the security group has been created, we can continue with limiting group creation permissions.

Make a remote PowerShell connection to the tenant to perform the rest of the configuration.

The exception has to be applied with a GUID, so lets get the GUID of the group we created for the exception:
[PS] C:\> $GA = (Get-AzureADGroup -SearchString "AllowGroup").ObjectId
Next, we need to create a new directory setting configuration:
[PS] C:\> $NewSetting = Get-AzureADDirectorySettingTemplate | where-object {$_.DisplayName -eq "Group.Unified"}
Now, we need to apply the desired settings to the configuration:
[PS] C:\> $Policy = $NewSetting.CreateDirectorySetting()
[PS] C:\> $Policy["EnableGroupCreation"] = $False
[PS] C:\> $Policy["GroupCreationAllowedGroupId"] = $GA
Finally, we need to create the actual directory setting using our desired policy settings:
[PS] C:\> New-AzureADDirectorySetting -DirectorySetting $Policy
We should verify that our new settings are in place. Lets look at the values of the directorty setting.
[PS] C:\> (Get-AzureADDirectorySetting).Values

The output should look something like this:
Verify the values ‘GroupCreationAllowedGroupId’ and ‘EnableGroupCreation’ are set as expected.

We can also test by logging in to an account that should not be able to create groups and attempting to create a new O365 Group. Through Outlook, you should receive the following message:
Users should receive this or a similar message from anywhere within the tenant when they try to create an Office 365 Group.

I put this script, along with a simple script to undo these changes on GitHub. In case you prefer to download scripts that way, they are available here.

Office 365 Customized Help Desk Information

As the administrator of an Office 365 tenant, you will want to make sure that support contact info is readily available. One way of providing support info is through the help desk card. The help desk card provides conveniently located support info for your users within Office 365. Once the card has been configured, users can access the help desk info through the ? icon in the upper right of many Office 365 pages:

 

Configuring a custom help desk card is very easy from the Office 365 Admin center. You will need to log in to your tenant using an account with Global Administrator privileges. Once in the Admin center, browse to Settings and then Organization profile. Scroll down and find Provide customized help desk contact info and select Edit.

 

You will need to enable the help desk card before you can configure the custom settings. Give the card a title and select the fields that are applicable to your organization.

You will see the support contact options under the help icon throughout Office 365, once you have saved the custom settings.

 

No Stupid Questions: Should I run Anti-Virus on my Exchange Server?

Well… YES! I would highly recommend running some form of antivirus software on your Exchange servers. It increases security for your Exchange organization. However, it isn’t as simple as just installing the AV software on your server. If you don’t take the time to correctly configure the antivirus software to run with Exchange, you are going to cause performance and stability issues.

To try and help simplify the configuration, Microsoft provides a list of exclusions for each version of Exchange. These list are helpful in understanding what files and processes need to be excluded from scanning. I should also point out that you should be sure to use the exclusions for the correct version of Exchange. Each version of Exchange server requires different exclusions. Because taking the time to accurately configure the exclusions manually can be time consuming, Microsoft MVP Paul Cunningham created a great PowerShell script to create the exclusions lists for you. The script only supports Exchange 2013 and Exchange 2016, but is definitely worth checking it out. I have found it to be very useful.

Why Exclusions are Needed

To help us understand why exclusions are needed, lets take an extremely high level look at how typical windows antivirus software works. Antivirus software usually consists of two functions, file-level scanning and real-time scanning. File-level scanning checks files on the server for possible viruses or malware. And real-time scanning checks all files and processes that are loaded into active memory. What we need to avoid, is the potential for a database or log file to become unavailable to Exchange because the antivirus software has it locked or even quarantined. By configuring the correct exclusions, we can ensure that the antivirus software doesn’t scan any files or processes that are needed by Exchange. Keeping your Exchange server running smoothly and interruption free.