Disabled or inactive User Accounts in M365 - a prerequisite for Governance

 

Among the many "triggers" in SharePoint Online these are the ones with the greatest impact:

Content created

Content updated

User Account disabled

Today we are taking a look at the latter and how to detect that a User Account no longer is active, as this is the primary trigger for a lot of governance actions.

You might expect that a key property of a User Account such as if it is active should be pretty obvious, but it is NOT. (unless HR remembers to inform you) 

The fellowing approaches to detecting disabled or inactive user account is available as a PnP Script Samples PowerShell script 😊

First of all, what do we mean by "User Account"? 

Are we defining this as a User Profile in the SharePoint User Profile Application (UPA)?

Are we talking about the Users endpoint in Microsoft Graph?

The answer is YES, as both can be used to decide if the User Account is active.

HideFromAddressLists

In the UPA we have the SPS-HideFromAddressLists property which, as the name implies, is used to hide the account from a address list. This property is synchronized into the UPA and originates in Exchange and is used to exclude the account from the Global Address List (GAL).

Once the SPS-HideFromAddressLists property changes to true, it is very often a good indicator that the User Account has been disabled. 

In Microsoft Search this property is the only way to exclude accounts from being shown.

Customer AD Properties

Another option is that the organization have added a customer User Profile Property like "EmployeeStatus"/"UserDisabled" and this property is sync'ed from AD/AAD to SharePoint via a customer sync job. 

I have even seen an organization where the UserAccountName was prefixed with ZZ[YearOfLeaving] as a way to tag the user as disabled 😮

Please consult your friendly Entra ID admin for details if the organization is using this approach.

Graph 😃

Using Graph we can query the Users endpoint to get the accountEnabled property

However, you will have to check with the Entra ID team in your organization to verify when Accounts gets disabled and if it is a good indicator that the employee no longer is with the Organization. 

Perhaps you will have to check if another criterium is fulfilled, like no licenses assigned, in order to determine that the user has been off-boarded.

No Activity

Yet another way to query if the user is inactive is to use the Auditlogs in Graph to check if the user has been active within the last X days.

https://graph.microsoft.com/v1.0/auditLogs/signIns?$top=1&$filter=userPrincipalName eq 'LeeG@tcwlv.onmicrosoft.com'

 The absence of logins is not a bullet proof way to detect that the user no longer is with the Organization, but it is a pretty good indicator.

Summary

The above should make it clear that we most likely will have to test a number of criteria in order to determine if we should start the governance actions, like rerouting the workflows assigned to the user in question, reassign ownerships on assets and so on.

The list of criteria will probably vary from organization to organization, but using the right mix should give you a good chance to detect those users.

#SharingIsCaring

Deleting File Versions to reduce the SharePoint Storage Consumption

 

This is a fellow-up post on the MS365thinking: Don't pay more for SharePoint Storage than you have to :-) post, where I went through the options you have when reducing the SharePoint Storage consumption.

The first action could be to reduce the default number of versions from 500 to a more reasonable number, like 50.

This will minimize any future storage increase but will not delete any existing versions. So, we will have to trim the existing libraries. 

In this post I will show how you can reduce the consumption using the PnP.PowerShell command Remove-PnPFileVersion

First of all, let's provide some evidens on how SharePoint storage is calculated in a way that will convince your management that you should investigate this.

This script will create a brand-new Modern SharePoint site collection (STS#3) or use the site collection specified by you.

DummyFileVersionGenerator

The script will then create a number of major and minor versions using a file provided by you:

#how many major versions the script should create

$majorVersionCount = 30

#how many minor versions that should create per major version

$minorVersionCount = 10

It will then calculate the current amount of SP storage used in this site collection.

If the file you provided is 5MB then we would expect the storage to be 5*10*30 = 1500 MB.

Wait...I have heard that Microsoft only saves the diffs when dealing with modern office files as these are XML files behind the covers. So the 300 versions of the file will only take up a smidge more than 5 MB, right?

Yes, you are correct, but that is not the way SharePoint storage is calculated :-) as Microsoft calculates this as the aggregation of File Size for each version of the file.

The re-calculation of Storage seems to be on a schedule so you should expect that the new storage numbers will take serveral hours before it shows up in the Admin center

Once we can see the Storage being consumed on our site collection, it is time to bring out the harvester:

File Version Trimmer | PnP Samples

Please be aware that the script is a sample and NOT production grade code. That will most likely be a number of questions you will need to address before you can start trimming the file versions.

Typical questions could be:

• Which Site Collections should not be trimmed.
• Which archived Site Collections should be unarchived and trimmed and then archived again.
• Are we going to use the same pruning parameters on all sites, or should we only trim the minor versions on some Site Collections.
• Are some of the files tagged as records and should receive special treatment
• and so on :-)

 

Have fun and remember Sharing is caring