[BUG] Request-PnPReIndexWeb stopped working

[Tetronic]

Reporting an Issue or Missing Feature

Running "Request-PnPReIndexWeb" does not increase the property bag value "vti_searchversion" of my connected SPO Web.

Expected behavior

I would expect that the value of the property bag key "vti_searchversion" would increase, as it is, when I manually do the reindex via the UI (under site settings -> Search and offline availability)

Actual behavior

The property bag value does not increase. Before the execution it was 19 and after the execution it is still 19.
To check this, I used the command "Get-PnPPropertyBag" after I connected to the web via "Connect-PnPOnline":
The relevant line of the "Get-PnPPropertyBag" - output is:
vti_searchversion 19

I even disconnected and reconnected via "Connect-PnPOnline", but it still gives me the vti_searchversion 19.

Steps to reproduce behavior

`

$SiteURL = "xxx"
$AppID = "xxx"

function DoFullCrawlForCurrentWeb() {

try{

Request-PnPReIndexWeb

Write-Host "Current Web is marked for Full Crawl" -ForegroundColor Green

}
catch {
write-host -f Red "Error at marking Current Web!" $_.Exception.Message
}

}

Connect-PnPOnline -URL $SiteURL -Interactive -ClientId $AppID

$WebsCollection = Get-PnPSubWeb -Recurse -IncludeRootWeb

ForEach ($Web in $WebsCollection) {

Write-Host "Processing Web: "$Web.Url -ForegroundColor Blue

Connect-PnPOnline -URL $Web.Url -Interactive -ClientId $AppID

DoFullCrawlForCurrentWeb
Write-Host ""

break

}
`

What is the version of the Cmdlet module you are running?

3.1.0

Which operating system/environment are you running PnP PowerShell on?

• Windows
• Linux
• MacOS
• Azure Cloud Shell
• Azure Functions
• Other : please specify

[reshmee011]

@Tetronic : can you please confirm whether the actual indexing is done in the background when you run the cmdlet request-pnpreindexweb? The underlying API calls a CSOM function ReIndexWeb which probably skip increasing the value of the property vti_searchversion.

[Tetronic]

@reshmee011 : thanks for your quick response. I tested it now by uploading two documents and used the global search to find the documents. Before executing "Request-PnPReIndexWeb", I couldn't find them. After the execution the search returned them. So skipping to increase the property bag value is the reaspon. That's good, because that means the original problem of this issue is solved.
Anyways, maybe the PnP team could also increase the property bag value, to align the behaviour to the manual task via the UI, or at least add this info to the manual: https://pnp.github.io/powershell/cmdlets/Request-PnPReIndexWeb.html
I guess that would help more users other than me.

[reshmee011]

@Tetronic : Thanks very much for getting back to me and confirming that this isn’t an issue with the current cmdlet. I appreciate you taking the time to clarify.

That said, I’d suggest this may be more of an enhancement request rather than a bug. Personally, I’d be inclined to pursue an update to the documentation to clarify the expected behaviour.

I came across this blog post by Loitzl: https://blog.loitzl.com/posts/troubleshooting-sharepoint-online-search/.
It mentions that the vti_searchversion property value should increment, although I must admit I haven’t historically validated that property value myself.

Previously, I would have used Get-PnPSearchCrawlLog to verify the last crawled date of the site or list content to ensure the crawl process was functioning as expected. However, with Get-PnPSearchCrawlLog now deprecated, that option is no longer available, which makes validation more challenging.

[Tetronic]

Yes, I agree, now it's a enhancement.
Yeah, without Get-PnPSearchCrawlLog it's difficult to determine whether the search flag was increased or not. I will try to take a look into the code of "Request-PnPReIndexWeb" the following days, perhaps I could also verify that the vti_searchversion won't be increased.

[reshmee011]

The code is very simple, calling the CSOM method to request the indexing. I don't know how to check anymore without Get-PnPSearchCrawlLog whether it's working. As per blog https://blog.loitzl.com/posts/troubleshooting-sharepoint-online-search/, it seems it should have increased the vti_searchversion value automatically.

[reshmee011]

@Tetronic : the Get-PnPSearchCrawlLog is functional again, let me know if you see activity after triggering "Request-PnPReIndexWeb".

[Tetronic]

@reshmee011 great! Which build do I need to use for the updated code, the Nightly build? I can't see the Request-PnPReIndexWeb command mentioned in the changelog (https://github.com/pnp/powershell/blob/master/CHANGELOG.md).

[reshmee011]

@Tetronic : Sorry for not being clear enough. Nothing changed in the codebase. It's the same Request-PnPReIndexWeb cmdlet the issue you raised is related to. You can use Get-PnPSearchCrawlLog after triggering Request-PnPReIndexWeb to check whether the web/site have been reindexed.

[reshmee011]

@Tetronic : I checked and the reindexing is happening after triggering 'Request-PnPReIndexWebwithout updating the valuevti_searchversion. Since vti_searchversion` does not have any effect on the reindexing process, let me know whether I can close this ticket.

[Tetronic]

@reshmee011 : Thanks for your reminder. Today and yesterday I tested both cmdlets, also for two different tenants.
Results:

• Request-PnPReIndexWeb did not increase the vti_searchversion property bag value (this is nothing new for us)
• Get-PnPSearchCrawlLog gives me some crawl logs. However, it does not output new crawl logs after executing "Request-PnPReIndexWeb". Even not after I waited about 24 hours in between the two cmdlets.
  Besides that the cmdlet "Get-PnPSearchCrawlLog" is rather buggy: Sometimes it works and gives me crawl logs and sometime I just got the message:
  "Get-PnPSearchCrawlLog: Error: Attempted to perform an unauthorized operation.. Make sure you are granted access to the crawl log via the SharePoint search admin center at https://-admin.sharepoint.com/_layouts/15/searchadmin/crawllogreadpermission.aspx"
  this behavior is non deterministically, e.g. I execute it 7x times, the error comes and on the 8th try, the command works. But this has nothing to do with this issue.

Anyways, I would say, if the documentation of "Request-PnPReIndexWeb" (https://pnp.github.io/powershell/cmdlets/Request-PnPReIndexWeb.html) would be updated (specifying that this cmdlet does not increase the vti_searchversion - in opposite of the manual web frontend-action), you can close this ticket. Because it does lead to an update of the search index.

[reshmee011]

@Tetronic : Good point! Do you want to have a go updating the documentation, else I can do it? Agree no issue with the cmdlet itself.

From my test, before running Request-PnPReIndexWeb

After running the cmdlet, the crawltime updated to today,

[Tetronic]

@reshmee011 Thanks for your logs. Today I tested both cmdlets again in my two tenants and now the errors that I had with Get-PnPSearchCrawlLog are gone. My output is like yours - perfect! Perhaps the permissions I set to request the crawl log were not yet propagated to the entire cloud network, I don't know.
One mistake I did was that I omitted the "filter" param using "Get-PnPSearchCrawlLog", because I thought without the filter param I would always get all crawl logs ("all" means of the current web, all sub webs and all lists/libraries of the connected Site Collection). But this is not the case. With the filter param I get different logs, in this case the proper ones to see the effect of Request-PnPReIndexWeb. So now all works like expected.
Yes, I can updated the documentation. I will use this guide: https://pnp.github.io/powershell/articles/gettingstartedcontributing.html