Sunday, 16 December 2018

SharePoint Online Property Bag SPWeb Properties are not indexed by default

Problem:  Moving an on-prem SharePoint solution to SPO, I realised that SPO does not automatically index property bag values.

Initial Hypothesis:  The Search schema looks correct and automatically created the correct Managed Properties.  Asked our Microsoft representative and they sent us a link to enable property bag values in the search index.

Resolution: Be aware that you need to do some Powershell commands on your tenant and site collections when using SharePoint Online to make property bag settings appear in the search results.

More Info:
https://blog.kloud.com.au/2018/04/26/how-to-make-property-bag-values-indexed-and-searchable-in-sharepoint-online/

Saturday, 15 December 2018

ShareGate User Migration Gotcha

Problem:  Migrated an Extranet site with a large user base, and multiple users have the same name.  When a user is removed from AD, and running migration to the new farm, the AD automatically picks a different user and gives them the user that lefts permissions.

Example:
John Smith (john.smith@contoso.com) has been added to a site collection.
John Smith (@contoso) is removed from AD but still exists in the site collection permissions.
Ran Sharegate to move the content including user permissions to a new farm.
John Smith is added to the same SharePoint groups however, it has added john_smith@clientA.com

Initial Hypothesis: Sharegate tries to resolve the user and is incorrectly resolving the user's name and not the name in AD.  As the user has left the firm, the other user is being resolved and we end up with permission inconsistency.

I got this reply from Sharegate and can see that my issue happens at step 8.

"How Sharegate resolves users from the source to the destination"

"We look at the whole account name available, for matches to users at the destination through the SharePoint people picker.
Once we have a list of potential matches for your user, we go through the list of values below (in the specified order). We consider the account a match when we find the same values for one of these properties:
1.    Exact same account name
2.    Same normalized account name (without claims header)
3.    Same login and domain
4.    Same login
5.    Same login and domain (source login read from display name - this can happen when importing from file system because the account name is set as the display name)
6.    Same login (source login read from display name - this can happen when importing from file system because the account name is set as the display name)
7.    Same email address
8.    Same display name

9.    PrincipalType is not set or is a Security Group and same display name without domain"

Somewhat related:
https://sharegate.com/blog/unresolved-user-when-preserving-created-modified-sharepoint-migration

Monday, 3 December 2018

SharePoint Online Geo-Replication SPO/O365

Geo-replication/Multi-tenancy

Mid 2018 I outlined the state of Multi-geo on O365, the easier parts of Geo-Replication are already well handled and the changes are discussed in the the link.  This post focuses on SSO options today and the likely road-map.

O365 is moving towards multi-tenancy that will allow multinational companies to store data in compliance with country rules.  For instance EU data may not be allowed to be stored outside the EU but you already have your O365 tenancy based in the US.

Historically, most larger companies have chosen either the US or EU to base their data storage in.  If you wanted data to be stored in another region you had to buy another tenant with Microsoft strongly discouraged.

Microsoft, are working towards supporting O365 in multi geo-locations.  Basically, their are 2 parts: 1) User specific data (email, OneDrive) where we know where a user is based and their data is encrypted and stored in that country. and 2) group/team/country specific data (SharePoint) where the data itself may have residency rules.

This post looks at SharePoint data that is required to be stored in a specific country.

Options today:
1. On-Prem. : Have a SharePoint farm in each geo location, this requires a fair amount of thought to deal with SSO, Search, MMS, Content Types and UPA.
2. O365: Have multiple tenants (non are connected) in each location and connect your authentication up to each tenant.  The problem with option 2 is that each O365 tenant requires a separate Azure Active Directory.  This means that you will need to hook each O365 tenant up to a single MMS, Search service and poly-fill in the SSO process.  Imaging if you have 8 regional tenants for regulatory purposes.  To achieve SSO, you will need to create a central AAD, then connected each regional AAD to the central AAD.  Azure directory sync is needed, inviting members and guests, other companies AAD becomes and issue.  The image below outlines a possible pattern to solve this complex problem.


Coming Q1 2019 : Multi Geo tenant, that shall be the answer.  A lot of the multi-tenant is still in  preview so I shall be interesting to see mutil-geo tenancy when it goes into General Availability (GA) next year (+-Feb/March 2019).