In this article I will show how different sensitive labels affect UX on the standard Create new Team form. For testing I created 6 different sensitive labels with different Privacy and external sharing settings:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Let’s see how teams creation form looks like for each sensitivity label from table above.
1. Private
2. Public
3. Private or public
4. Private with external users
5. Public with external users
3. Private or public with external users
In my previous post I showed how to enable sensitivity labels for different containers (SPO sites, Teams, O365 groups) in the tenant . Let’s see in more details how exactly applying of sensitivity labels looks like and to which exact containers it can be applied.
First of all let’s go to Sharepoint Online and try to create new site there. We will see that sensitivity labels are available for Modern Sharepoint Online sites: both Modern Team site
and Modern Communication sites
But if we will try to create Classic site (e.g. using Publishing Portal site template) we will see that sensitivity labels are not available:
So for Classic Sharepoint sites sensitivity labels are not available.
Next let’s go to Teams and try to create new Team there: we will see that Sensitivity field appeared on the Teams creation form:
Finally if we will go to Azure portal and will try to create new O365/M365 group we will also see that Sensitivity field will be available:
In the future posts we will check other details of sensitivity labels functionality in O365.
Sensitivity labels help to maintain content in your organization. In opposite to classification labels which are more like additional metadata for O365 groups/SP sites where custom policies have to be enforced by internal tools or custom PowerShell scripts (i.e. don’t have O365 policies assigned to them) sensitivity labels have policies behind and allow to use O365 infrastructure to maintain sensitive data in your organization.
Sensitivity labels may be enabled from several places:
By default they can be used for files in emails but in order to enable them for “container” (SP online sites, Teams and O365 groups) several additional steps should be done:
1. First of all enable sensitivity labels from PowerShell using the following script:
Import-Module AzureADPreview Connect-AzureAD $Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id $Setting["EnableMIPLabels"] = "True" Set-AzureADDirectorySetting -Id $Setting.Id -DirectorySetting $Setting
2. After that we need to sync them to AzureAD using the following script:
Install-Module -Name ExchangeOnlineManagement Import-Module ExchangeOnlineManagement $UserCredential = Get-Credential Connect-IPPSSession -Credential $UserCredential Execute-AzureADLabelSync Disconnect-ExchangeOnline
If you will have error "It is about Unable to resolve package source https://www.powershellgallery.com/api/v2” then start new PowerShell session as administrator and run the following command as 1st command in the session:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
and then run above script again.
After these steps you will be able to create sensitivity labels for SP sites, Teams and O365 groups. Let’s see how it looks like in Security and compliance center > Classification > Sensitivity labels. Pay attention that there is now the following note:
You can now create sensitivity labels with privacy and access control settings for Teams, SharePoint sites, and Microsoft 365 Groups.
Click Create a label – after that New label wizard will be opened. On the first step we need tp specify name and description and on 2nd step it will be possible to choose both Files & emails and Groups & sites:
Here we are interested in Groups and sites so let’s keep only this option checked. Skip next step for Files and emails and open next step “Define protection settings for groups and sites”. On this step we may set “Privacy and external user access settings” and “Device access and external sharing settings”:
E.g. if we will check “Privacy and external user access settings” then on the next step we will be able to set privacy and external users settings for sites/teams/groups for which this label will be applied:
On the final step we will need to publish our new label (this will open own wizard).
After label has been published it will take up to 10 minutes before it will appear in O365 UI:
This is how you may enable sensitive labels for SP sites, Teams and O365 groups. Hope this information will help someone.
Few years ago I wrote about one problem in OfficeDevPnP method WebExtensions.WebExistsFullUrl: shortly when it was called with url which belongs to non-existent site collection from different managed path it returned true. Full description of the problem is available here: How to check does site collection exist by absolute url using CSOM in Sharepoint. Also I posted issue to PnP-Sites-Core in github: WebExtensions.WebExistsFullUrl returns true for non-existent sites from different managed path in Sharepoint 2013 on-premise. I checked this issue with the latest PnP version (which is 3.26.2010 at the moment of writing of this article) and found that this problem is fixed now by MS. I.e. code of WebExtensions.WebExistsFullUrl method is still the same:
public static bool WebExistsFullUrl(ClientRuntimeContext context, string webFullUrl)
{
bool exists = false;
try
{
using (ClientContext testContext = context.Clone(webFullUrl))
{
testContext.Load(testContext.Web, w => w.Title);
testContext.ExecuteQueryRetry();
exists = true;
}
}
catch (Exception ex)
{
if (IsUnableToAccessSiteException(ex) || IsCannotGetSiteException(ex))
{
// Site exists, but you don't have access .. not sure if this is really valid
// (I guess if checking if URL is already taken, e.g. want to create a new site
// then this makes sense).
exists = true;
}
}
return exists;
}
but now when we try to clone ClientContext in this line:
ClientContext testContext = context.Clone(webFullUrl))
and webFullUrl corresponds to non-existent site collection from another managed path (e.g. if context was created from the root site collection http://example.com and we pass webFullUrl = http://example.com/sites/som-non-existent-url) it throws System.Exception (System.Net.WebException) now:
The remote server returned an error: (404) Not Found
while in earlier CSOM version it created ClientContext for the root site in this case. And as result WebExtensions.WebExistsFullUrl returns false as expected. So fortunately issue was fixed and we can call this method for checking existence of different site collections.
In SPO there is one very useful OTB application layouts page groupstatus.aspx. Using this page we may redirect user to Notebook, Planner plan or Sharpeoint site associated with O365 group, e.g.
{siteUrl}/_layouts/15/groupstatus.aspx?target={target}
where {siteUrl} is url of the site associated with O365 group. And target may be "site", "notebook", "planner", etc. Full list may be found here: Generic URLs for all Office 365 Group connected workloads.
If we don't know url of the site associated with O365 group we may still use this page in context of the root tenant site and specify id of O365 group in additional query string parameter:
https://{tenant}.sharepoint.com/_layouts/15/groupstatus.aspx?target={target}&id={groupId}
In this case it will still redirect you to the requested target. And this is exactly how we use this page in TW - we open it in context of the root tenant site and provide target=site and id of the group in query string.
However at the same time Sharepoint has own redirection system for mobile devices: when you visit some Sharepoint site from mobile device it will redirect to special application layouts page optimized for mobile view \_layouts\Mobile\mblwpa.aspx (see Overview of Mobile Pages and the Redirection System). According to documentation this redirection for mobile devices is performed via http module (SPRequestModule). It means that in ASP.Net pipeline it will happen before request will come to groupstatus.aspx page. So when we redirect user to the root tenant site on mobile browser:
https://{tenant}.sharepoint.com/_layouts/15/groupstatus.aspx?target={target}&id={groupId}
Sharepoint will just redirect user to mblwpa.aspx page in this root site
https://{tenant}.sharepoint.com/_layouts/15/mobile/mblwpa.aspx
and instead of seeing site associated with specified O365 group - user will see root tenant site. Will try to report this problem to MS using available communication channels. For now posted this problem on StackOverflow here.
If you are lucky owner of PC with 100Gb OS SSD disk or when OS disk on your server is not big enough then you may face with situation when there is no enough space anymore for installing updates, new tools, etc. In this post I will share solution which will help to free some space on OS drive.
Probably the first thing which you will try when will face with this problem is WinDirStat tool which allows to gather report of disk space usage per folders. The same report will most probably show that C:\Windows\SoftwareDistribution folder takes a lot of space. This folder is used by Windows Update for storing temporary files needed for installing new updates. As it is important Windows component you can’t just delete or move it and free space on OS drive. However what we can do is to create folder on another drive, move files there and create junction between C:\Windows\SoftwareDistribution and this folder. Here are needed steps:
1. Stop Windows Update service (Control Panel > Administration > Services)
2. Create new folder on another drive with enough space, e.g. D:\WinSoftwareDistribution. This is where files will be stored after all
3. Rename C:\Windows\SoftwareDistribution e.g .to C:\Windows\SoftwareDistribution.old
4. Create junction between folders:
mklink /j C:\Windows\SoftwareDistribution D:\WinSoftwareDistribution
5. Move files from C:\Windows\SoftwareDistribution.old to D:\WinSoftwareDistribution. After that you may go to C:\Windows\SoftwareDistribution junction and ensure that files appear there again
6. Run Windows Update service
After that your SoftwareDistribution will be located on another drive and you will have more space on your OS drive. Hope that this trick will help someone.
Update 2022-08-19: there may be side effects which this solution. Workaround for one of them is described here: Fix for "The system cannot open the device or file specified" error in Windows Installer.
In previous article I showed how to enable universal links for iOS on Sharepoint on-prem site – see How to enable iOS universal links in web-facing Sharepoint on-prem site. In this post I will describe how to enable Android App links for web-facing Sharepoint on-prem site.
For Android App links the process is different. First of all we need to prepare special assetlinks.json file with predefined content:
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "...",
"package_name": "...",
"sha256_cert_fingerprints": ["..."]
}
}]
I won’t describe here details about content of assetlinks.json file – you may find this information on Android documentation sites. Next step is to place assetlinks.json file into .well-known subfolder of the root folder of our site. On Sharepoint we can create this folder in site’s IIS folder C:\inetpub\wwwroot\wss\VirtualDirectories\{SiteName}.
After that we need to go to IIS manager > choose Sharepoint site > right click .well-known sub folder and click “Convert to Application”:
When .well-known subfolder is ready and configured in IIS manager we may copy assetlinks.json file there.
Now we need to make assetlinks.json file available for anonymous access (otherwise it won’t be available for Android infrastructure) and ensure that server adds Content-Type: "application/json" http header in response. In order to do that add the following web.config file to .well-known subfolder:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
<system.webServer>
<staticContent>
<clear />
<mimeMap fileExtension=".json" mimeType="application/json" />
</staticContent>
<handlers>
<remove name="JSONHandlerFactory" />
</handlers>
</system.webServer>
</configuration>
After that Android App links will be available on your web-facing Sharepoint on-prem site.