-1. On your website or team site, click **Share**

-2. By default, the **Share** dialog that appears displays the message **Invite people to Edit** or **Invite people**. This invites the users who you add to join the SharePoint Members group. To choose a different group and permission level, click **Show options** and then choose a different SharePoint group or permission level under **Select a group or permission level**.

- 

-1. In the **Enter names, email addresses, or Everyone** box, enter the name or email address of the user or group that you want to add. When the name appears in a confirmation box below your entry, select the name to add it to the text box.

-

-2. If you want to add more names, repeat these steps.

-

-3. (Optional) Enter a personalized message to send to the new users in **Include a personal message with this invitation**.

-4. Click **Share**.

-> [!IMPORTANT]

-> Even if your organization-level setting allows external sharing, not all new sites allow it by default. The default sharing setting for Microsoft 365 group-connected team sites is "New and existing guests." The default for communication sites and classic sites is "Only people in your organization."

-These recipients are added to your directory as guests provided that [SharePoint and OneDrive integration with Azure AD B2B](sharepoint-azureb2b-integration.md) is enabled.

-

-You can stop sharing with people who have an "Anyone" link by going to the file or folder that you shared and deleting the link.

-With restricted access control, you can ***restrict site access to members of specified [Azure AD security groups](/windows-server/identity/ad-ds/manage/understand-security-groups)*** using [SharePoint PowerShell](/powershell/sharepoint/sharepoint-online/introduction-sharepoint-online-management-shell). Users who aren't members of the specified security groups can't open the site or its content even if they previously had site access permissions. **You can apply restricted access control on a site with up to 10 security groups.**

-> - You can add up to 10 Security Groups for a given site.

-To remove a security group from a restricted access control configuration for the non-group site, run the following command:

-description: "In this article, you'll learn about syncing SharePoint and OneDrive files using the OneDrive sync app for Windows and Mac."

-When users add, change, and delete files and folders on the site, the files and folders are automatically added, changed, or deleted on their computer and vice versa.

-To upload files to the team site, users can simply copy or move them to the site in File Explorer or Finder. They can also use File Explorer or Finder to easily organize the document library by creating new folders, and moving and renaming files and folders. All these changes sync automatically.

-Both options allow essentially the same thingΓÇöusers can access files on their local computer in Explorer or Finder. However, adding OneDrive shortcuts allows content to be accessed on all devices, whereas sync is related to a specific device. Additionally, OneDrive shortcuts offer improved performance versus using the sync button.

-We recommend using OneDrive shortcuts as the more versatile option. If you want to remove the Sync button from all the SharePoint libraries in your organization, you can use the [Set-SPOTenant](/powershell/module/sharepoint-online/set-spotenant) PowerShell cmdlet:

-Removing the sync button blocks new syncs from being started but does not affect existing syncs.

-## Related topics

-> [Azure Active Directory external collaboration settings](/azure/active-directory/external-identities/external-collaboration-settings-configure) determine who can invite guests in your organization. Be sure to review Azure AD guest access settings as part of your SharePoint and OneDrive sharing setup.

-

-

-> [!IMPORTANT]

-> [Allowed or blocked domains in Azure AD](/azure/active-directory/external-identities/allow-deny-list) also affect SharePoint and OneDrive. Be sure to review Azure AD collaboration restrictions as part of your SharePoint and OneDrive sharing setup.

-By default, guests can receive an invitation at one account but sign in with a different account. After they redeem the invitation, it can't be used with any other account.

-If people who use a verification code have selected to "stay signed in" in the browser, they must prove they can still access the account they used to redeem the sharing invitation by entering a code sent to that account.

-Host-named site collections are the preferred method to deploy sites in SharePoint Server. Because the Microsoft 365 environment uses host-named site collections, new features are optimized for these site collections and they're expected to be more reliable. Learn how to plan for and implement host-named site collections, design URLs, and manage URLs.

-Host-named site collections enable you to assign a unique DNS name to site collections. For example, you can address them as `http://TeamA.contoso.com` and `http://TeamB.contoso.com`. This example shows that you to deploy many sites with unique DNS names in the same web application. It also enables hosters to scale an environment to many customers. If you don't use host-named site collections, your SharePoint web application will contain many path-based site collections that share the same host name (DNS name). For example, Team A has a site collection at `http://contoso.com/sites/teamA`, and Team B has a site collection at `http://contoso.com/sites/teamB`.

-We recommend host-named site collections unless requirements dictate that path-based sites with alternate access mapping are necessary (described later in this article). This article describes how to implement host-named site collections in a recommended configuration with SharePoint Server. Information about advanced configurations is included at the end of this article: [Use multiple web applications with host-named site collections](host-named-site-collection-architecture-and-deployment.md).

-The recommended configuration for deploying sites is using host-named site collections with all sites located within a single web application, as illustrated in the following diagram.

-When creating a Web application for host-named site collections, the URL of the Web application and the root site collection will be `http://<_webapp.contoso.com_>/`.

-

-This architecture is recommended to deploy sites because it's the same architecture that the Microsoft 365 environment uses. So, this configuration is the most heavily tested configuration. New features, including the App model and Request Management, are optimized for this configuration, and it's the most reliable configuration going forward.

-|URL mapping|Use PowerShell commands to manage URLs (Set-SPSiteURL, Remove-SPSiteURL, Get-SPSiteURL).|Use Alternate Access Mappings to manage URLs.|

-> To use different zones you need to extend existing web application.

-The protocol used for a host-named site collection depends on the value of the Url parameter that you specified when you used the Set-SPSiteURL cmdlet to map the URL to a particular zone: http or https. Ensure that the IIS bindings for the web application, SSL certificates, reverse proxy configuration, and any other configuration necessary is complete.

-Although we recommend host-named site collections for most architectures, you should use the traditional path-based site collections and alternate access mapping if any of the following conditions apply:

-Host headers allow the web server to host multiple web sites on the same IP Address and Port combination. If the incoming HTTP request includes a host header name, and a matching host header is configured in IIS, IIS will respond with the content from the appropriate web site.

-Host headers are configured at the Web Application (IIS web site) level, they're one of the website bindings properties.

-It's important to understand the distinction between Host headers in IIS and Host Named Site Collections. Host headers at the IIS web site level are only intended for path-based site collections.

-When using Host named site collections, SharePoint is responsible for resolving the correct site for the address based upon the incoming request passed through IIS. In most cases, applying a host header binding at the IIS web site level makes it impossible to access host-named site collections through the IIS web site. This inaccessibility is because IIS won't respond to requests for host names that differ from the host header binding.

-> If an existing web application has a host header binding set, IIS won't return pages from the host-named site collection until you remove the binding from IIS. For more information, see [Update a web application URL and IIS bindings for SharePoint 2013](update-a-web-application-url-and-iis-bindings.md).

- An administrator can use the **Add-SPShellAdmin** cmdlet to grant permissions to use SharePoint Server cmdlets.

-A root site collection is a requirement for any Web application. It's also necessary for crawling content. This site collection must have the same URL as the Web application. Currently, SharePoint prevents the creation of a host-named site collection with the same URL as a Web application. Therefore, the root site collection is created as a path-based site collection.

-You must use Microsoft PowerShell to create a host-named site collection. You can't use the SharePoint ServerCentral Administration web application to create a host-named site collection, but you can use Central Administration to manage the site collection after you have created it.

-You can create a host-named site collection by using the Microsoft PowerShell New-SPSite cmdlet with the -HostHeaderWebApplication parameter, as shown in the following example:

- An administrator can use the **Add-SPShellAdmin** cmdlet to grant permissions to use SharePoint Server cmdlets.

-This syntax creates a host-named site collection that has the URL, https://portal.contoso.com, in the SharePoint Server web application that has the URL, https://portal.contoso.com.

-You can implement managed paths with host-named site collections. Hosters can provide multiple site collections to the same customer with each site collection sharing the customer's unique host name but differentiated by the URL path after the host name. Managed paths for host-named site collections are limited to 20 per farm. For more information, see [Software boundaries and limits for SharePoint Server 2016](../install/software-boundaries-and-limits.md#WebApplication).

-When you migrate from SharePoint Server 2010 to SharePoint Server, we recommend that you determine how SharePoint Server 2010 sites were created. If sites were created as path-based sites, consider migrating these sites to host-named site collections. If host-named and path-based sites were implemented together, identify the sites that were created as path-based sites and consider migrating these sites to host-named site collections. To accomplish this migration, look for the 'HostHeaderIsSiteName' flag.

-The following example determines if a site within a given web application is created as host-named or path based:

-|Within IIS|Associate an SSL certificate (wildcard certificate or SAN certificate) for all host-named site (domain) in the web application.|Associate an SSL certificate in IIS for each zone (each zone is a separate web application in IIS).|Associate an SSL certificate (wildcard certificate or SAN certificate) for a host-named site (domain) in the web applications. <br/> On each web server in the farm and for each web application that shares a port: <br/> Configure a separate IP address to represent each web application. <br/> Edit the IIS web site binding manually to remove the host header binding that was created when the web application was created and replace this binding with an IP address binding.|