Browse Category

Office 365

Removing Permissions for Viewing Modern Personal Blogs in Office 365

A personal blog can be a great tool for you to contribute your thoughts and ideas. Office 365 provides the capability for everyone to have a personal blog that can be accessed via your profile page. 

When you create a new blog post this will be automatically be view-able by all employees. If you do not want to have this capability or manage this in any way it can be done via PowerShell. The example I put together will remove viewers access from all existing blogs so they can only be seen by the owner.

To get started we need a high level understanding of what these blogs are and how they work. I won’t go into all of the details of this because Benjamin Niaulin has already put it together in this great post:

The highlights to support this post are:

  • When a user follows the links to create a new blog post a new site collection is built with the managed path of /portals/personal with a site name of your user account
    • i.e. tenant.sharepoint.com/portals/personal/dmadelung
    • These are not viewable in any SP Admin center and Get-SPOSite will not work
  • Site collections are only built after a user initiates the creation so not all users will have one
  • Blog posts (stories) are creates at pages in the pages library on your site collection
  • Permissions are handled with SharePoint permissions and inherited down with a Contributors, Creators, and Viewers SharePoint Group
    • The viewers group includes “Everyone except external users” by default
  • The blogs are NOT deleted when a user leaves like their OneDrive site collection

And here are details the details from Microsoft around personal blog posts in Office 365:

Removing existing permissions via PowerShell

As this is all hosted in SharePoint there could be multiple ways that we can control these. Unfortunately I couldn’t find a way to control things as scale but there is a small UserVoice submission for it. What I wanted to ensure was that creators could still get to their content but no one else could view anything. The path I took to manage these was through PowerShell and CSOM (Client Side Object Model)

Here is link to the GitHub repo and I will break it down below along with the script.

Here are some key things to note:

  • I can not confirm that doing this is the best practice but it was the easiest way I found to control these without a any administrator controls available to us. 
  • This is currently built to run on demand but could be updated to run on a schedule via something like Azure Automation.
    • To catch everything it will need to run on a schedule because any future sites will not be caught.
  • This could be updated to be used as a reporting tool or identification tool for cleanup.
  • I would comment out the actual removal of the permissions and put some logging in to test before fully running.
    • Also if you have any changes please update the repo!
  • This queries the user profile service in SharePoint Online to get the full list of users which could be huge.
    • I didn’t test this on a very large environment so this could take awhile to run or need to be enhanced for scale.
  • All of the user profile gathering was copied from this post from Microsoft on how to display a list of OneDrive for Business site collections

To get started with CSOM & PowerShell with SharePoint Online here is a good blog post from Chris O’Brien. You can get the latest version of SharePoint Online CSOM here. If you download the nuget file you can change the file extension to .zip and extract the .dlls.

To utilize the script make sure you fill out the appropriate variables and more information about what this will do is below the script. Make sure you test any script you get online before you really run it!

The end result will be that all existing blog sites will have anyone in the Viewers SharePoint Group removed

Before…

After..

Office 365 Groups Naming Policy

group1

Introduction

When Office 365 Groups were first released there was not an ability to control the names of Groups at all. One of the primary reasons for this was due to the cross workload functionality that make up Office 365 Groups. As a reminder, an Office 365 Group is the single Azure AD identity service that provides specific membership to Office 365 solutions like SharePoint, Exchange, Planner, Teams, etc. Within each of these workloads you have the ability to create and manage an Office 365 Group. If you make a change within one of workloads, for example SharePoint, there is communication between the workload and Azure AD with notifications on things like creation, changes, and deletions. 

With a separated system and Azure AD as the source, any policies need to be applied at the Azure AD level. As an example, an Exchange naming policy can be used (and at one point was the only option) for Office 365 Groups. If you set a naming policy within Exchange that would only work if you tried creating a group within Exchange. If I was on SharePoint Home and tried to create an Office 365 Group that naming policy would not trigger as I technically not working in Exchange. Exchange would learn about the Group after it is synced back to Azure AD but that would be too late. 

To resolve this issue Microsoft has released Office 365 Group naming policy capabilities at the Azure AD level. A naming policy is very important for proper control and a clean Global Address List (GAL). Since this is in Azure AD now the naming policy is applied to Groups that are created across workloads. 

Details

As I am writing this post in Dec 2017 this is currently still in Private Preview. 

Both of these currently can only be configured with PowerShell. The prerequisites for configuring these can be found in this post: Managing Office 365 Groups using Azure AD PowerShell V2.

The AzureADPreview PowerShell module version 2.0.0.137 is required.

Office 365 Group naming policies can be built using 2 different features and 1 is automatically maintained:

  • Custom blocked words
    • You can set specific blocked words that can be used within Group names. 
  • Prefix-Suffix naming policy
    • Using fixed strings or user attributes, you can add an automated prefix or suffix to a Group name. 
  • Microsoft Standard blocked words list
    • A set of words Microsoft manages that are not allowed. This includes your primary swear words. I tested quite a few good ones and they were all blocked automatically.

These administrators bypass or are exempt from the naming polices you configure but NOT the MS standard blocked words list:

  • Global Administrator
  • Partner Tier 1 Support
  • Partner Tier 2 Support
  • User Account Administrator
  • Directory Writers

Microsoft detailed information for the naming policy can be found here.


Custom blocked words

This is a comma separated list of words that you can configure. These words are blocked in Group names and aliases. Some examples of when you would want to configure blocked words:

  • Your department or business function names because you want to ensure you don’t have duplicate places for content
  • Regulatory words that you may have specific legal requirements around that you need to have more control over
  • Names of roles that you don’t want people to try to impersonate
  • Client, Vendor, or Competitor names

There are some things to know about these blocked words.

  • The checks are done AFTER appending the prefix/suffix to the Group name
    • If things like underscores (_) or dashes (-) are used in prefix/suffix they could stop your blocked word from working if there are no spaces
  • No sub-string searches are done
    • If “Drew” is the blocked word, “Andrew” would still work
  • Not case-sensitive
  • No character restrictions
  • No limit on the amount of words

Steps to set the Custom Blocked words

This is assuming you already have a directory settings template created, details in prior post, and connection information from the first section.

1 – Connect to Azure AD via PowerShell.

2 – Use comma delimited values for the blocked words.

3 – Review your updated settings; you can now see the default values for the directory settings object.


Prefix-Suffix naming policy

These can either be fixed strings or actually attributes from the user themselves. These 2 types of capabilities are stored within 1 overall string that is concatenated. Because of this, you must always have [GroupName] included in your setting. That is how you are able to have a prefix & a suffix. 

Some examples of using strings:

  • GRP [GroupName]
    • This puts the fixed string of “GRP ” before all of your Group names
  • #[GroupName] Group
    • This will put the # symbol at the front of the Group name for better sorting in the GAL and then ” Group” as a suffix for better clarity
    • Special characters are removed from the Alias
  • OGRP – [GroupName]
    • Dashes can be used for separation as spaces are removed automatically in the Group Alias (like the rest of the special characters). That means “OGRP – Drew” as a group name becomes “OGRP-Drew@domain.com” as the alias instead of “OGRPDrew@domain.com”.

The next type of thing you can add are Azure AD user attributes. The following attributes are supported: [Department], [Company], [Office], [StateOrProvince], [CountryOrRegion], [Title], [CountryCode]

Some examples of using attributes:

  • [Department] – [GroupName]
    • This will pull the users department stored in Azure AD before the Group name
  • [CountryCode] – GRP – [GroupName]
    • This will first put the Country Code stored in Azure AD followed by a fixed string and then the Group name

There are some things to know about using attributes.

  • The total prefix/suffix + string length is restricted to 53 characters
  • Empty attributes for users will be filled in with blank values. It is best to ensure your Azure AD information is fully established before using these attributes.
  • Extension attributes and custom attributes are not supported
    • If you put it in an unsupported attribute it just comes across as text

Steps to set the Prefix – Suffix naming policy

This is assuming you already have a directory settings template created, details in prior post.

1 – Use comma delimited values for the blocked words.

2 – Review your updated settings; you can now see the default values for the directory settings object.


Microsoft standard blocked words

There are a lot of unprofessional words naturally in the English language that most likely should never be part of an Office 365 Group name. This includes a primary set of things like swear words and other inappropriate words that your imagination may be able to come up with. This is a single setting to turn on the blocked words or off. 

Steps to set the Microsoft blocked words

This is assuming you already have a directory settings template created, details in prior post, and connection information from the first section.

1 – Use comma delimited values for the blocked words.

2 – Review your updated settings; you can now see the default values for the directory settings object.


And when you put it all together!

You get a blocked word of CEO and a naming policy pulling in a prefix of “GRP – ” with an Azure AD department of “NFL” and a suffix of ” – CEO”. You will also see the alias removing the spaces.


Where does the naming policy actually work?

As there are a lot of workloads across Office 365 that utilize Groups there are a lot of places that these policies need to work. Currently it is not supported in every workload. Microsoft has the detailed information for what is supported in their support article here

Here is the current breakdown in Dec 2017.

Where it works:

  • Outlook on the Web
  • Outlook Client – Doesn’t preview
  • Outlook Mobile – Doesn’t preview
  • Teams
  • SharePoint
  • Stream
  • Groups mobile app
  • Planner
  • Dynamics 365
  • Exchange PowerShell
  • Azure AD PowerShell
  • O365 Admin Center

Where it doesn’t:

  • Power BI workspace
  • Yammer
  • StaffHub
  • Azure AD Portal

Licensing

Any Office 365 subscription that has Exchange Online and SharePoint Online will support groups. That includes the Business Essentials and Business Premium plans, and the Enterprise E1, E3 and E5 plans.

There is a large collection of features that require specific types of Azure AD licenses. The Office 365 Groups naming policy requires Azure AD Premium P1 licenses for any users who are part of Office 365 Groups.

The full collection of licensing information is listed from Microsoft here.

View When You Deleted an Office 365 Group

group1

Introduction

The ability for soft-delete and restore of an Office 365 Group has recently been released. I put together some information about that in my previous post here. Before this restoration was possible, when you deleted an Office 365 Group it was fully gone. Now we have the ability to view Groups that have been deleted and restore them using PowerShell.

The ability to restore was a great but there was a small gap for me when the cmdlets were first rolled out:

  • You have 30 days to restore an Office 365 Group but you didn’t know when an Office 365 Group was deleted. 

This would make building any logic around things like notifications or reporting a challenge as we could not tell which Groups were about to expire. 

This has been resolved by Microsoft and we now have the ability to see the Deleted Date and Time of an Office 365 Group for the 30 days it is retained using PowerShell. 


What you need to know

  • You can only view the deletion date via PowerShell
  • You can only view the deletion date of Groups that are in the pending permanent delete state that stays around for 30 days

Prerequisites:

  • Azure AD PowerShell V2 – Preview 
    • The release of the cmdlets that support Office 365 Group recovery are now available only in the preview cmdlets. 
    • I am writing this using version 2.0.0.110

Viewing when an Office 365 Group was deleted

1 – Connect to Azure AD via PowerShell (ensure you connect to Preview)

2 – Review the Office 365 Groups that have been deleted and when they were deleted

This will sort the Groups by their DeletedDateTime

You are now good to go build something fancy like:

  • Build a report for admins to notify them weekly what Groups are being permanently deleted
  • Build a single page app to surface deleted Groups and allow users to recover them using an Azure Function

Recovering a Deleted Office 365 Group via PowerShell

group1

Introduction

Ever since Office 365 Groups were released which feels like many moons ago now, when it was deleted, it was unrecoverable.  So if you either on purpose or accidentally deleted an Office 365 Group you lost all your data.  You lost your SharePoint site, Planner data, Outlook mailbox…all of it.  There was a checkbox that you had to check in most places letting you know that deletion was permanent.  What began happening though with the proliferation of Groups throughout Office 365 there was a ton of ways and places to delete a Group.  Last time I tried counting there was at least 16 different ways to delete a Group.  That is a ton of places for UI to be just different enough and someone to make a mistake.  This was also a large concern for regulated or very security aware environments.  The ability to discover and recover critical data can be mandatory in these environments.  That means the lack of ability to restore Groups could be a single bottle neck to stop usage of such a helpful technology. 

Thankfully our wait is now no more and we can recover a deleted Office 365 Group.  The message that this was rolling out appeared in Message Centers today and the Office 365 Roadmap has already been updated that this has been launched. 

Here is the announcement on the Tech Community site and the supporting Microsoft Documentation


NOTE: I am writing this right around the launch date of this feature and will try to keep this post updated if anything changes

What you need to know

  • Currently you can only recover them via PowerShell with GUI coming later
  • You have 30 days from the deletion of the Group to recover it, if not it will be permanently deleted
  • You cannot restore a group if a group with the same SMTP address or alias now exists (that new group would have to be deleted first)
  • It could take up to 24 hours to restore in rare cases
  • You can permanently delete a Group within the 30 days 
  • Content that currently gets restored includes:
    • AD Groups Object including properties and members
    • SMTP address
    • Exchange mailbox & calendar
    • SharePoint Online site
    • OneNote notebook hosted on the SPO site
    • Planner
    •  Additionally if you have a connected Microsoft Team or Office 365 Connected Yammer group those can be restored as well

Prerequisites:

  • Azure AD PowerShell V2 – Preview 
    • The release of the cmdlets that support Office 365 Group recovery are now available only in the preview cmdlets. 
    • I am writing this using version 2.0.0.98 

Steps to recover a deleted Office 365 Group

In my example I have a Group called InterestGroup1 which was deleted and can no longer be seen:

1 – Connect to Azure AD via PowerShell (ensure you connect to Preview)

2 – Review the Office 365 Groups that have been deleted and can be recovered 

I included the list of properties in this for visibility to see everything returned in the recoverable Group object.  You only need Get-AzureADMSDeletedGroup,  ”  | select * ”  is not required. 

3 – Select the Group you want to recover and ensure that you selected a group

Replace “ENTER GROUP DISPLAY NAME HERE” with the appropriate name of the Group you want to recover.  I put this together so you just need to enter the Group Display Name instead of copying the GUID but entering just the ID is also valid in the next step.

4 – Recover your Group

You can run the command from step 2 above to review that your Group you are recovering is no longer in the Deleted Group list.

5 – Confirm you Group has been recovered

After some time it will start popping back up in the GUI.


Steps to permanently delete an Office 365 Group

You can also delete a Group that is in the pending 30 day deletion using this process.  This will delete everything and not be recoverable. 

1 – Follow steps 1 through 3 above to connect to Azure AD and get the group you want to recover in the $deletedgroup variable.  

Instead of using the Restore-AzureADMSDeletedDirectoryObject cmdlet use the Remove-AzureADMSDeletedDirectoryObject cmdlet and passing the Group ID.

2 – Review the Office 365 Group has been deleted

 

Automatically Created Office 365 Groups Based on Direct Reports Coming Soon – (Now Limited Release)

group1

UPDATE 3/21/2017 from Microsoft

Microsoft has released a new update to this roll out stating: 

**We listened to your concerns and have decided to limit the rollout of this feature to a smaller set of customers (notified via MC94808) whom we will work with directly to ensure feedback is considered, and the feature has a positive impact. We thank you all for your constructive feedback, we have learned a few lessons and look forward to continued Group innovations in the future.**

So thankfully the voice of the community has been heard and this below information now relates to the original global release.  There was a ton of discussion around this on the MS Tech Community site and on Twitter. 

Here is the new message in the message center:

Now back to the original post with some slight tweaks….


Last Friday an interesting new message that caught me off guard popped up in my message center titled – Auto creation of Direct Reports group in Outlook

Here are the contents of the message:


Auto creation of Direct Reports group in Outlook
MC96611
Published On : March 17, 2017
Expires On : April 28, 2017
 
To help managers collaborate more effectively with their employees, we will automatically create Office 365 Groups containing the manager’s direct reports. Managers can easily update, delete, or modify the group at any time. This message is associated with Office 365 Roadmap ID 78174.
 
How does this affect me?
Beginning April 13th , 2017 We will automatically create direct reports groups in Outlook (leveraging the Office 365 Groups Service) for eligible managers. If you have Office 365 Groups disabled for your tenant, or if the manager in question doesn’t have permission to create groups, then no group will be created.
 
What do I need to prepare for this change?
If you are looking forward to this, there is no action you need to take. Get yourself familiar with Office 365 Groups, update your user training, and notify your helpdesk, as needed. If you would like to leave Office 365 Groups enabled for your organization but turn off direct reports groups creation, we have provided controls to enable and disable. Please click Additional Information to learn more.

Let’s go a little more into this…

At first glance this sounds like a good idea. The part that I disagree with is the auto opting-in of something like this and the very late notice. Normally things exist on the O365 Roadmap for awhile and fall intro their standard development and release cadence. This one is being rolled out within a month of the announcement and doesn’t have info if it will be first-release to start. This feature has the ability to create a whole ton of Groups depending on the size of your organization whether you are ready for them or not. The majority of the large clients I work with have not fully jumped into the Groups world yet and are working towards basic governance, adoption, and training strategies before they fully go. For those organizations, they could already have a plan to provision groups for specific teams – company teams not the product 🙂 – they will most likely get these new Groups created before they are ready. In the documentation currently they don’t list anything for the continued update of groups either. If this is a one time push there will need to be onus on the Managers to maintain their Groups post auto creation. I would still say there are more questions to be answered for this feature and there is already a good discussion on the MS Tech Community site
 
Another thing I noticed is the new naming of this release. The title specifically calls out that these are Groups in “Outlook”. This looks like a new way to refer to Email (Outlook) conversation based Groups vs Yammer conversation based Groups. 
 
As stated above this is no longer going to be rolled out to everyone and will be rolled out to a limited subset of tenants. 

How will the members of the Groups be determined?

The member population of these Groups is based on your Active Directory ManagedBy attribute. As you’re reading this, raise your hand if you think your ManagedBy attribute is accurate enough in you Active Directory environment? Now lower your hand because you are just reading this post and and someone near you might think you have a question. If you have any direct reports (i.e. your name is listed in someone’s ManagedBy attribute) you potentially could have a group auto created. The manager will be added as an Owner of the Group while everyone else will be added as Members. 

How can I control these auto provisioned Groups?

Some key things to note:
  • This is on by default. I felt like I just needed to repeat this one again. 
  • Office 365 Group creation must be enabled at the tenant.  I have highlighted how to manage this in a few posts on here
  • The manager must have the permission and ability to create an Office 365 Group.
  • The group will be named “<Manager’s Name>’s direct reports”, but that can be edited.
  • You can only turn this off via PowerShell and connecting through Exchange Online (unlike Azure AD for other Group management). 

Steps to manage auto provisioning of Direct Reports Office 365 Groups via PowerShell

1 – Connect to Exchange Online via PowerShell

2 – Review your current settings for the parameter “DirectReportsGroupAutoCreationEnabled” using the Get-OrganizationConfig cmdlet. 

 

2 – Set the value of “DirectReportsGroupAutoCreationEnabled” to false to disable auto group creation and true to enable it. Review your change with the same cmdlet above.