Category Archives: SharePoint

Microsoft 365 Search: roadmap and announcements

updated: June 3, 2021

(Old) SharePoint Search: content-centric (SharePoint Search Center)
(New) Modern Search: people-centric (Teams, Office, OneDrive, Delve etc.)

Office graph = codename for collective set of services and insights we generate on top of the infrastructure that fast office graph group developed 
= social Intel concepts (SharePoint home, Delve, OneDrive Discoverview) are derivatives of Office graph 

Microsoft Graph = API ( including universal search API)
The Graph Search API went General Availability (GA):
– Microsoft Search API in Microsoft Graph
– Use the Microsoft Search API to query data

Microsoft Search API provides one unified search endpoint that you can use to query data in the Microsoft cloud – messages and events in Outlook mailboxes, and files on OneDrive and SharePoint – that Microsoft Search already indexes.

Turing technology – understands you, answers your question e.g. hover over doc -> doc summary (based on “deep speed” AI model)
announcement at Ignite23-pages blog  

Modern Search: MS nailed the fundamentals, now start bringing it everywhere  – to Teams first, then SharePoint (Nov 2020).

Modern Search Customizations  – we’ll take the best from Classic SharePoint Search,
a lot will retire – investing in more flexibility  

PnP modern Search
– custom result pages, webparts, branding theme; filters, refiners, scoping control  ) 
pnp modern search – webparts (video)
https://microsoft-search.github.io/pnp-modern-search

Core idea behind Microsoft search is coherence 

Bill Baer:
“People use search in a different ways 
1) you have organisations who have a well-established intranet built around set of governance controls, a very clean architecture and they want to build a search into that intranet scenario; that’s why a lot of SharePoint capabilities are going to come along with Microsoft search for that particular endpoint
2) then you have other people who live their day in teams“

Shared search engine results page (developed once – transitioned everywhere)
Ctrl-F to search through teams (chats?) (contextual search)
Outlook search – more natural language
Image search (before eoy), + 
teams chats, outlook groups conversations, yammer conversation -> bing, office.com, sharepoint
bookmarks (new promoted results)

Targeting bookmarks for the specific audience based on device/OS, region, security groups

SharePoint Search Admin Center -> will be migrated from SharePoint admin center to to Microsoft Search Admin Center transitioning (Search and Intelligence Admin Center) – long-running project custom dictionaries, spelling suggestions – will retire, (move to a graph-driven spellar) 

promoted results -> bookmarks
acronyms
Q&A 

Graph Connectors
Graph Connectors are generally available (Azure Data Lake Storage Gen2, Azure DevOps, Azure SQL and Microsoft SQL Server, Enterprise websites, MediaWiki, File share, Oracle SQL, Salesforce, ServiceNow + 100+ from partners; New connectors coming to Microsoft Search: Jira Graph connector, Confluence Graph connector).

Graph Connector allows to connect external source of information to Microsoft 365 and makes that data available across all m365 apps and services so you can find what you need wherever you’re working, whether in one of your favorite productivity apps or one of the many Microsoft 365 services such as SharePoint or Office.com

Actionable experiences
Search results on select Graph connectors will soon support actions that will allow users to interact with the result and perform changes to the Connector content within the Search application.

Results clusters
The results shown in a result cluster are grouped together based on the search vertical configuration.

Profile Query variables
Define any attribute from the user’s Profile, as a query variable and it would be resolved during query evaluation (This feature is currently in preview)

Profile enrichment with Graph connectors
…you will soon be able to enrich Microsoft 365 profile properties like Job title, Phone numbers, Skills etc. with data from HRMS systems using graph connectors. …then surface this rich profile information on people experiences like profile cards.

Search Federation
federation capabilities will allow enterprises build and integrate their custom LOB search experiences, customized search providers, into the overall Microsoft Search. With federated search, you can make information from systems where the data cannot leave the systems boundaries available to search across in Microsoft 365 productivity apps and services, without indexing its data with Microsoft Search.

Federation with Azure Cognitive Search

PowerBI search vertical

Custom verticals and custom refiners

Custom result templates – search layout designer – wysiwyg editor
– Manage search result layouts
– Microsoft Search Layout Designer

Standalone Search  – AAD identity – Graph connector – Ingest your data – use Search = in Windows 10, Office.com  ( e.g. for those who have their data in other productivity suite, have no intent to use m365, but want to search)

More info:

Office 365 Search scopes

References

Current state of SharePoint Search and Microsoft Search scopes

https://techcommunity.microsoft.com/t5/microsoft-search-blog/microsoft-search-at-ignite-2020/ba-p/1651098

https://techcommunity.microsoft.com/t5/microsoft-search-blog/what-s-new-for-microsoft-search-ignite-2020-edition/ba-p/1675291

Bill Baer: What’s new and what’s next for Microsoft Search (May 25, 2021)

Bill Baer on Search:

Microsoft 365 Search Roadmap

Track Service Principals in Microsoft 365

Scenario

Developers in the organization use both – Azure Apps and SharePoint Apps to work with SharePoint sites in their “daemon” applications. You want to know – what are SharePoint Apps registered, who register SharePoint Apps.

One of the approaches – track Apps/Owners with Unified Audit Log

Use Unified Audit Logs

The following PowerShell code:

$operations = 'Add service principal.'
$recordType = 'AzureActiveDirectory'
Search-UnifiedAuditLog -StartDate $start -EndDate $end -ResultSize $resultSize -Formatted -Operations $operations -RecordType $recordType

returns events with operation = ‘Add service principal.’ Nice, but…
if an app was registered in Azure – event will contain user UPN under UserIds property:

Unfortunately, in case with registering app in SharePoint, an audit log event will be like:

i.e. UserId registerd is “spo_service@support.onmicrosoft.com”, so we do not know who registered a SharePoint-only app

I’m wondering – can we use events recorded immediately before and after “Add service principal” event to track a user who has registered a SharePoint-only app…

References

Read access: Read items that were created by the user via PowerShell

Scenario:

You have a list in SharePoint Online. You want list items be visible to specific users only.
You want to leverage Item-Level Permissions under List Advanced settings: “Read access: Read items that were created by the user”. But the problem is it was not users who created items. E.g. the list was imported from excel file or created programmatically or migrated.

Solution:

PnP.PowerShell helps. Using “Set-PnPListItem”, you can re-write “Author” field in the list item.

Set-PnPListItem -List "Test" -Identity 1 -Values @{"Author"="testuser@domain.com"}

And, of course, use Item-Level Permissions under List Advanced settings: “Read access: Read items that were created by the user”:

Add users to “Site Visitors” group for read-only access:

… more TBP

Find sites shared with Everyone in SPO

There is a know problem in SharePoint – it’s complicated permissions system. As a result, many sites are overshared (overexposed) and site owners/administrators even do not know – who has access to their sites…

The most concern is sites shared with “Everyone”, “Everyone except external users” and “All users”. How do we find sites shared with “Everyone” in a large Microsoft 365 tenant?

Approach #1 (Brute force)

We can get full permissions report at tenant level (or permissions provided to “Everyone”). There are 3-rd party tools (e.g. ShareGate, SysKit, AvePoint, Metalogix etc.), or you can run PowerShell script…

Sounds easy? Well, if you have 1000 sites – probably yes. But if your environment 10K+ sites – it will take forever. Permission report might run hours for an average site with site/subsite, list/library and list item details level.

We need report detailed up to every item level deep, as even one file with sensitive info shared with everyone can cause security issue.

So, if this approach is not working – what’s working?

Approach #2 (Search)

Clever idea: why do we have to iterate through all the tenant documents/items if all the content is already crawled by search? Can we just use search to get files shared with Everyone? Sure!

Check this and this articles. Can we get results programmatically (e.g. with PowerShell)? Can we use Microsoft Graph search API? Sure.
Check this article “How to search against SharePoint Online Content with Microsoft Graph search API with PowerShell”.

But! We have two problems here.

Search Problem #1. The problem is the same as in “brute force”. Search returns so many results – it’ll take weeks to get all of them. (There are team sites “legally” shared with everyone, public Office 365 group based sites, communication sites… ).

Search Problem #2. Even whet we get all search results – we do not know – what is the exact Url of the resource shared with all users. So we will need to build list of sites based on the search results – ant then still need to run permissions report against these sites.

Approach # 3 Hybrid

The idea: why do we need to get all search result if even one result from the site would be enough to add the site to the list of sites require permission report.

So, consider (imho, the best) approach.

  1. You get list of sites in tenant. Here you can refine the list excluding, e.g. sites connected to public teams or known communication sites… Finally wou’ll have a list of sites you want to check – if there are resources shared with “Everyone…”
  2. You run search against each site in the loop (e.g. consider KQL option “Site: https://yourTenant,SharePoint.com/sites/YourSite”. Once even one result fount for the site – add the site to the “Open Sites” list

With this approach you will get list of sites shared with “Everyone…” in a coule of minutes.

The Next step would be “How to let site owners know what are resources shared with Everyone… on their sites”.

References

Authenticate to Microsoft Graph from PowerShell Interactively

Scenario

You are a developer or power user in a company with Microsoft 365 tenant.
You need to connect to Microsoft Graph and then call Microsoft Graph API to consume some MS Graph resources on behalf of authenticated user programmatically with PowerShell – e.g. add/remove documents or list items, search for sites or documents content etc. – whatever available with Graph API.

You do not have tenant admin permissions or any tenant-level admin permissions (SharePoint, Teams, Exchange etc. ). But you can register an Azure App and request tenant admin consent.

Solution

  • register an Azure App
  • under authentication blade – add platform – “Mobile and Desktop app”
    add “http://localhost” (and select …/nativeclient Url ?)
  • under API permissions blade – add delegated permissions you need
    (refer to specific API you’ll use)
  • install MSAL.PS PowerShell module
  • use the following code to get graph access token and call graph API
$AppId = ""
$TenantId = ""
$connectionDetails = @{
    'TenantId'    = $AppId
    'ClientId'    = $TenantId
    'Interactive' = $true
}

$token = Get-MsalToken @connectionDetails
# or 
$token = Get-MsalToken -TenantId $TenantId -ClientId $appId -Interactive 

$Headers = @{
    'Authorization' = "bearer $($token.AccessToken)"
}

Invoke-RestMethod -Uri 'https://graph.microsoft.com/v1.0/me' -Headers $Headers

You can find the code sample here: https://github.com/VladilenK/

Did not work:

Az PowerShell module did not work for me:

Connect-AzAccount -Tenant ""
$azAccessToken = Get-AzAccessToken -Resource "https://graph.microsoft.com" 

$Headers = @{
  'Authorization' = "$($azAccessToken.Type) $($azAccessToken.Token)"
}

Invoke-RestMethod -Uri 'https://graph.microsoft.com/v1.0/me' -Headers $Headers

As I understand we need somehow let Azure know API permissions we want (e.g. via app registerd)…

PnP did not work for me too:

$url = "https://orgname.sharepoint.com"
Connect-PnPOnline -ClientId "" -Url $url -Interactive 
$pnpToken = Get-PnPGraphAccessToken 
$Headers = @{
    'Authorization' = "bearer $($pnpToken)"
}
Invoke-RestMethod -Uri 'https://graph.microsoft.com/v1.0/me' -Headers $Headers

# did not work as well:
$pnpToken = Get-PnPAppAuthAccessToken
$pnpToken = Get-PnPAccessToken

the error message was (maybe I missed something – please let me know):

“code”: “InvalidAuthenticationToken”, “message”: “Access token validation failure. Invalid audience.”

References

Access SPO Site Programmatically via MS Graph API and SharePoint API

Scenario

You are a software developer. Your company uses Microsoft Office 365 (SharePoint, Teams etc.). The need is to work with a specific site collection programmatically (from code – Python, C#, Java, PowerShell, JavaScript etc.) – e.g. upload/download documents, update list items, search etc. The code must run without user interaction (unattended, aka daemon app).

The solution is based on a new Graph API feature – Sites.Selected and a classic SP-Only app.

Solution

  1. Register an Azure App
  2. MS Graph API permissions: add -> Microsoft Graph -> Applications Permissions -> “sites.selected”
  3. Ask SharePoint/Tenant admin run PowerShell code (e.g. this one) to assign proper permissions to your azure app for a specific site collection (consider site owner consent)
  4. SharePoint API permissions:
    Site Collection Owner/Admin – use
    https://YourTenant.sharepoint.com/teams/YourSite/_layouts/15/appinv.aspx
    to add SharePoint API permissions to your app.
    Consider minimal permissions (e.g. as per Sumit)

Problem Solved

  • you get access to one and only one site collection (“least privilege” principal)
  • you get both – SharePoint API and Microsoft Graph API permissions to SharePoint
  • you can use app secret or certificate to authenticate – depending on what are your security requirements

References:

LED Downlight Kit 6-inch 3CCT YUURTA: review

Another great experience with Yuurta LED Recessed Lights.

This time I happened to test 6 Inch LED Dimmable 3CCT
3CCT means you can select color temperature. Options are: 3000K (Warm White), 4000K (Natural White), 5000K (Daylight).

Quality is good. Manufacturer gives 5 year warranty and expected lamp life is 50,000 hours! It is Ultra Slim and easy to install – no housing required


Connectors are included.

btw, there is a Video – unpack and review YUURTA 6-inch LED lamp.

A new Recessed Lights Online Store: DownLights.Store

SharePoint sites shared with Everyone and Microsoft Delve issue

There is a known problem with Microsoft Delve.

We know SharePoint site permissions are not easy. You can break permissions inheritance at any level – subsite, library, list, folder, list item or specific document. Anybody with full permissions can do that. The worst thing is there is was (*1) no one place where site owner could get full permissions report to the site. We must have used third-party tools or PowerShell to have all permissions in one document.

So no wonder SharePoint sites were heavily over-exposed. Especially when a site owner tired with complexity of SharePoint permissions system decided to share resource with “Everyone”. That is the real issue.

Now, what happens when sites are migrated to Microsoft 365 SharePoint Online with Microsoft Delve enabled by default? Delve works as it should work – it suggests to you documents it believes related to you (based on Microsoft Graph insights) and you already have access to.

What happens is people start seeing documents they never new they have access to. Where these documents from? Of course from sites shared with Everyone.

So strictly says, it is not Delve’s problem. It’s more human problem than technological.
Delve just does it’s job, and does perfectly.

How do we solve the issue?

  1. Disable Delve?
  2. Disable search (stop sites crawling and remove results)?
  3. Restrict access to Microsoft Graph ?
    e.g. Microsoft KBA on how to disable MS Graph for a specific User

Those methods are half-measure. 1-2-3 methods are just hiding the problem – not solving it. Agree it helps stop the deterioration, bud does not fix the issue.

How do we solve the root cause of the issue?

  1. Of course, we need remove incorrectly provided permissions. How?
  2. Only site owner (data owner) knows which content should be shared with whom with which access rights. So we need to ask sites owners to review their permissions. How?
  3. First, we need a list of over-exposed sites. How? There are two methods
    (more details – check this article)
    • Brute force – use PowerShell or 3-rd party tool to get permission report on all sites in tenant, select permissions provided for Everyone…
    • Smart move – use Microsoft search. As search is security-trimmed, we can search for available content on behalf of a user with no permissions provided.
  4. Then we need a list of sites and their owners. How?
    1. tbp
  5. Finally, we need to let every site owner know that his site is Open to everybody and ask to fix it. How?
    1. tbp
    2. inform the site owner how to get full permissions report to his site,
      e.g. KBA How To Get SPO Site Full Permissions Report
      and video “Full Permissions Report for a Team SPO Site Owner“


References