You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/solution-guidance/multigeo-managedmetadata.md
+13-15Lines changed: 13 additions & 15 deletions
Original file line number
Diff line number
Diff line change
@@ -9,32 +9,30 @@ ms.localizationpriority: medium
9
9
10
10
Managed metadata in SharePoint is Multi-Geo-aware. This article describes how to manage metadata in a SharePoint Multi-Geo tenant.
11
11
12
-
The managed metadata that you define for the default geo ___location of a Multi-Geo tenant automatically replicates to the tenant's satellite locations. Managed metadata that you define for a satellite geo ___location is only available to the sites that are hosted in that geo___location.
12
+
The managed metadata that you define for the default geo ___location of a Multi-Geo tenant automatically replicates to the tenant's satellite locations. Managed metadata that you define for satellite geolocation is only available to the sites that are hosted in that geo-___location.
13
13
14
-
In the example shown in the following image, the term groups TGMain1 and TGMain2 were created in the default geo ___location and are replicated to all satellite geolocations. As a result, those terms are available to all locations in the Multi-Geo tenant.
14
+
In the example shown in the following image, the term groups TGMain1 and TGMain2 were created in the default geolocation and are replicated to all satellite geo-locations. As a result, those terms are available to all locations in the Multi-Geo tenant.
15
15
16
-
Term set synchronization is one way from the default to the satellite geolocations. Term sets created in a satellite ___location do not sync to the default or other satellite geolocations. For example, term sets created in TGEurope1 are only available to sites hosted in Europe.
16
+
Term set synchronization is one way from the default to the satellite geo-locations. Term sets created in a satellite ___location do not sync to the default or other satellite geo-locations. For example, term sets created in TGEurope1 are only available to sites hosted in Europe.
17
17
18
18
19
19
20
20
The following are important points to know about managed metadata in Multi-Geo tenants:
21
21
22
-
- Replication from the default geo ___location to any satellite geo ___location is **one way**. Users can't update replicated term sets in satellite geo locations, but administrators can. However, we don't recommend this because it results in having additional term sets and terms available in that satellite geo ___location.
23
-
24
-
- Create term groups, term sets, and terms in the default geo ___location. This ensures that they are consistently available across all the geo locations in your tenant.
25
-
26
-
- When term groups, term sets, and terms are replicated across geo locations, they retain their ID. This allows you to reference term groups, term sets, and terms based on ID, regardless of the geo ___location your code is running in.
27
-
28
-
- For term sets and terms to be replicated across geo locations, they need to be set as Available for Tagging.
29
-
22
+
- Replication from the default geolocation to any satellite geolocation is **one way**. Users can't update replicated term sets in satellite geo locations, but administrators can. However, we don't recommend this because it results in having additional term sets and terms available in that satellite geo ___location.
23
+
- Create term groups, term sets, and terms in the default geo ___location. This ensures that they are consistently available across all the geo-locations in your tenant.
24
+
- When term groups, term sets, and terms are replicated across geo-locations, they retain their ID. This allows you to reference term groups, term sets, and terms based on ID, regardless of the geo-___location your code is running in.
25
+
- For term sets and terms to be replicated across geo-locations, they need to be set as Available for Tagging.
30
26
- The incremental replication process runs hourly. The full replication job runs every three days.
31
-
32
27
- When you programmatically create a term set in the default geo ___location, that term set is automatically replicated. You don't have to make any changes to the APIs.
33
-
34
-
- In some cases, you might want a term group, term set, or terms to be available only in a satellite ___location, for example, a term that relates to a confidential project that applies to a specific geo ___location. In that case, you can choose to create the relevant terms in the applicable geo ___location.
35
-
28
+
- In some cases, you might want a term group, term set, or terms to be available only in a satellite ___location, for example, a term that relates to a confidential project that applies to a specific geolocation. In that case, you can choose to create the relevant terms in the applicable geo-___location.
36
29
- If you want the term group to be available only in the default ___location, use the `Set-SPOTenantTaxonomyReplicationParameters` PowerShell cmdlet to explicitly specify which term groups from the default ___location are replicated. This cmdlet is part of the [SharePoint Online Management Shell](https://www.microsoft.com/download/details.aspx?id=35588).
37
30
31
+
> [!NOTE]
32
+
> In a multi-geo scenario, there are protected or special term sets within the term store space that will not be replicated, nor will anything under them be replicated. Those groups are:
Copy file name to clipboardExpand all lines: docs/solution-guidance/security-webapppolicies.md
+11-11Lines changed: 11 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
---
2
2
title: Alternative model for web app policies in SharePoint Online
3
3
description: Web app policies are a concept that allows SharePoint administrators to either grant or deny permissions to users and groups for all sites under a web application. These permission grants and denies take preference over the permissions set at the sites in the web application and therefore are a mechanism typically used in multiple scenarios.
4
-
ms.date: 12/14/2020
4
+
ms.date: 8/10/2023
5
5
ms.prod: sharepoint
6
6
author: vesajuvonen
7
7
ms.author: vesaj
@@ -17,7 +17,7 @@ Web app policies are a concept that allows SharePoint administrators to either g
17
17
- Grant support team read-only access to all sites so the support engineer can walk through the site with the end user
18
18
- Deny users (e.g. after leaving the company) access to all content
19
19
20
-
Web application policies do not exist anymore in SharePoint Online and there’s no identical alternative implementation possible, however by using the existing SharePoint security model you can achieve similar results. In this article and video you’ll learn more about this.
20
+
Web application policies do not exist anymore in SharePoint Online and there’s no identical alternative implementation possible, however by using the existing SharePoint security model you can achieve similar results. In this article and video, you’ll learn more about this.
@@ -28,11 +28,11 @@ Web application policies do not exist anymore in SharePoint Online and there’s
28
28
Before starting to implement permissions grants it’s important to understand why a grant was needed. Questions to ask yourselves are:
29
29
30
30
- Is granting access to **all** data in your SharePoint Online tenant necessary? Push back and verify that the access to **all** data is an absolute must to support a business scenario
31
-
- Is the “one” using the granted permission an application or a user? If it’s an application then it might be possible to work with an app principal having SharePoint Online tenantwide permissions, especially if this is an inhouse developed application
31
+
- Is the “one” using the granted permission an application or a user? If it’s an application then it might be possible to work with an app principal having SharePoint Online tenant-wide permissions, especially if this is an in-house developed application
32
32
33
-
Below flowchart is capturing these questions:
33
+
The below flowchart is capturing these questions:
34
34
35
-
35
+
36
36
37
37
> [!IMPORTANT]
38
38
> Only in the case the granted access will be consumed by a user or an application that is not compatible with app principals should you grant access via users or groups. If possible, prefer app principals above users and groups because:
@@ -75,7 +75,7 @@ You can achieve the same result by either granting the permissions to a user or
| Clarity | A group can contain on or more accounts, typically not visible to the other site collection administrators | User account is always visible, there’s no doubt about it |
78
+
| Clarity | A group can contain one or more accounts, typically not visible to the other site collection administrators | User account is always visible, there’s no doubt about it |
79
79
| Maintenance | You can easily grant access by adding new members to the group | New members must be added to all sites |
80
80
| Tamper proof | A group can shield the actual accounts having access (e.g. legal account) and other admins are less likely to remove the permissions for the group | There’s full transparency, other admins might be more likely to remove the “weird” users from their site |
81
81
@@ -84,23 +84,23 @@ You can achieve the same result by either granting the permissions to a user or
84
84
85
85
#### What about modern team sites (a.k.a. group sites)?
86
86
87
-
Modern team sites are SharePoint team sites which are connected to a Microsoft 365 group. This Microsoft 365 group acts as a central model for granting access to all the services on top of that group (e.g. SharePoint Site, Exchange mailbox, Planner, …). For these sites, you do have 2 options for granting access:
87
+
Modern team sites are SharePoint team sites that are connected to a Microsoft 365 group. This Microsoft 365 group acts as a central model for granting access to all the services on top of that group (e.g. SharePoint Site, Exchange mailbox, Planner, …). For these sites, you do have 2 options for granting access:
88
88
89
89
- Add user accounts (no groups) to either the members or owners of the Microsoft 365 group connected to the modern team site. The advantage of this approach is that the granted permission applies to all services that use this group, but when evaluating web app policies this typically is not relevant
90
90
- Treat the modern team site like a “normal” site and grant permission like described in earlier chapters
91
91
92
92
> [!IMPORTANT]
93
-
> We recommend granting permissions at SharePoint level, so treat the modern team sites like regular classic SharePoint team sites. This approach aligns with what the web application policies were providing.
93
+
> We recommend granting permissions at the SharePoint level, so treat the modern team sites like regular classic SharePoint team sites. This approach aligns with what the web application policies were providing.
94
94
95
95
#### Granting permissions using PnP PowerShell
96
96
97
-
Below scripts show an easy way to grant access via using PnP PowerShell and they can be a good starting basis for your implementation. Below scripts do not take in account the following:
97
+
The below scripts show an easy way to grant access via using PnP PowerShell and they can be a good starting basis for your implementation. The below scripts do not take in account the following:
98
98
99
99
- Get-PnPTenantSite is currently not enumerating modern team sites
100
100
- Get-PnPTenantSite is not Multi-Geo aware
101
101
- Performance is not optimal since the scripts are sequentially running, there’s no parallel execution
102
102
103
-
Since users continuously create new site collections it’s important to run these scripts on regular basis, ideally as a scheduled task.
103
+
Since users continuously create new site collections it’s important to run these scripts on a regular basis, ideally as a scheduled task.
@@ -113,7 +113,7 @@ To give users full control to specific (or all) SharePoint sites, you can use Sh
113
113
It is recommended that access be added on an as-needed basis, and then removed. For example, the script below assigns a list of administrators to all site collections in a tenant. The example uses the [SharePoint Patterns and Practices (PnP) of PowerShell commands](https://aka.ms/sppnp-powershell) to make two users admins of all site collections in the tenant.
114
114
115
115
```PowerShell
116
-
# commaseparated list of users and groups to be added
116
+
# comma-separated list of users and groups to be added
This release focuses on new features within the Viva Connections side and evolving existing capabilities within the other areas on building Microsoft 365 solutions with SharePoint Framework.
@@ -187,4 +187,4 @@ The default outline icon for Teams-hosted web parts is now transparent. This all
187
187
188
188
We are interested on your feedback around the release. Please do let us know any findings or other feedback using the [SPFx issue list](https://github.com/SharePoint/sp-dev-docs/issues).
0 commit comments