Quick-fix Orphan Site Blocks Patch

Quick-fix Orphan Site Blocks Patch

Issue

After applying Cummulative Updates to SharePoint, it can happen that you are facing an issue with orphan sites in one or more content dbs.

As these are flagged as errors, the configuration wizzard that needs to be run after the bits have been applied to all servers, cannot complete the job and will fail.

Error

06/29/2016 07:17:54.93 OWSTIMER (0x4D38) 0x4F84 SharePoint Foundation Upgrade SPContentDatabaseSequence ajxkz ERROR Database [SP_DVT_INSIGHT_ContentInsightDB_01] contains a site (Id = [54916e1a-54f3-43d0-ae74-d2915ab4e55f], Url = [/Workspaces/WS_002250]) that is not found in the site map. Consider detach and reattach the database. 39cc8a9d-a8ae-a04a-f205-a18cb49efb20

Solution

The solution is to detach the content db where the orphan site has been detected and then mont the database back in. After the database is back in its place, you can locate the orphan site and delete it. (If you are curious, you should be able to browse to that orphan site, just to double check there is no critical content in it).

high level steps

  • Detach mentioned content db
  • Mount mentioned content db back in
  • Delete orphan site
  • Restart configuration wizzard

doing

Get-SPContentDatabase [DB] | Dismount-SPContentDatabase
Mount-SPContentDatabase [DB] -DatabaseServer “SP-SQL-FARM” -WebApplication [DEFAULT ZONE URL OF THE WEB APP]
Remove-SPSite [ORPHANSITE-MENTIONED IN LOG]

 

 

Fresh Search Results with SharePoint

Fresh Search Results with SharePoint

How fresh do you want your search results?

Introduced with SharePoint 2013 we have got a new feature for Search in order to support better content freshness. Its called continious crawling. The name suggests SharePoint is crawling and processing content continiously. The truth is – by default – it is a type of incremental crawling in 15 minutes intervalls with a few extras.

Once we know something, we find it hard to imagine what it was like not to know it.

Chip & Dan Heath, Authors of Made to Stick, Switch

Continious crawling

…is a type of crawl with the purpose to maintain the index as current as possible by fixing the shortcommings the incremental crawling has.

Incremental crawling

…is sort a of crawling where existing content in the index is being crawled again – e.g. picking up changes.

Full crawling

…kicks off content discovery of the entire content source.

 

30 Minutes

15 Minutes

Every Sunday

Use continious crawling for SharePoint content – it is not availible for indexing external content e.g. BCS, File Share and Websites. With continious crawling enabled you will benifit from parallel indexing of content.

Imagine some major changes are happening on the content and the crawling needs more time than usual to process them. With continious crawling the next crawl wont wait for complition – he will kick off as scheduled and will process the latest changes – crawling is running in paralel.

Situation

Simon is a project manager and is introducing a lot of changes to large documents in a short time. During the changes the SharePoint crawling is kicking in and while this happens, Anita, who is working in finance is uploading her calculation and expects it to be aggregated and displayed in the finance portal by search driven webparts.

Without continious crawling

Anita has to wait for the current crawling to be finished, so that the next crawling can start and processing her calculation sheet. On some environments even incremental crawls can take up to 60 minutes. So in worst case Anita has to wait [60 Minutes + Time for the current crawl]. This behaviour will irritate the users – depending on how heavily the portal relys on search – it will likely cause some headaces to the management as users will complain if your portal is completely search driven.

With continious crawling

While a crawl is running to process the “deep” change, another crawl kicks in after 15 Minutes in parallel and is eventually processing Anitas excel sheet. Even if one crawling needs longer due to processing of “deep” changes, another crawl will begin its work as per schedule, without being bothered by any other crawls.

Use continious crawling on all SharePoint content sources and if your farm has the power .e.g. is fast responding to user requests during crawls and you want users to have super fresh search results – change the continious crawling schedule. It is 15 Minutes per default.

 

$IntervalMinutes = 10;
Write-Host "Changing Continuous Crawl Interval to $($IntervalMinutes) minutes"
$ssa = Get-SPEnterpriseSearchServiceApplication
$ssa.SetProperty("ContinuousCrawlInterval",$IntervalMinutes) 
$ssa.Update()
$interval = (Get-SPEnterpriseSearchServiceApplication).GetProperty("ContinuousCrawlInterval") 
Write-Host "New continuous crawl interval set to $interval"
Changing continuous crawl interval

User property check – help yourself script

User property check – help yourself script

Get-UserProfiles – Get your own user profile report

Ever wanted to check  your profile store in terms of usage or correct data for a specific property in all profiles?

Download this tiny script to accomplish your mission.

.\Get-UserProfiles.ps1 -PropertyConstant [PropertyConstant]

[Download]

Check this site for all OOB Property Constants http://msdn.microsoft.com/en-us/library/microsoft.office.server.userprofiles.propertyconstants_fields.aspx

The script needs to be run – of course on a server that is part of the Farm where your User Profile Service sits on.

 

Migrieren von Benutzern

Migrieren von Benutzern

Nachdem ein Domänen Benutzer im Active-Directory umbenannt oder dieser in eine andere Domäne migriert wurde, muss man als SharePoint Administrator das Kommando stsadm -o migrateuser oder Move-SPUser ausführen, damit das neue/migrierte Konto die SharePoint Berechtigungen erhält.

Hier ist die Snytax für das veraltete stsadm.exe Kommando

stsadm -o migrateuser -oldlogin -newlogin [-ignoresidhistory] stsadm -o migrateuser -oldlogin HSD\Bob1 -newlogin HS\Bob

Hier ist die entsprechende Syntax für den selben Vorgang, nur mit dem PowerShell Cmdlet und ensprechender Syntax

Move-SPUser [-Identity] -NewAlias [-AssignmentCollection ] [-Confirm []] [-IgnoreSID ] [-WhatIf []]
Move-SPUser -Identity “HSD\Bob1” -NewAlias “HS\Bob”

Wann immer die Fehlermeldung – DS_NAME_ERROR_DOMAIN_ONLY auftaucht, liegt es daran, das der SidHistory check fehlschlägt.

Das Kommando migrateuser/Move-SPUser sucht in der SIDHistory des neuen Accounts den alten Account (Neuer Account->Prüfe ob es einen Eintrag gibt->OLDName->NEWName)

In folgenden Fällen wird das Kommando Fehlschlagen, da kein Eintrag in der SID Historie des neuen Accounts gefunden werden kann.

  • Der Benutzeraccount wurde nicht umbenannt, sondern neu erstellt
  • Der Benutzeraacount wurde in eine andere Domain transferiert

Im ULS sieht die Meldung dann wie folgt aus:

stsadm: An error occurred while translating user name ‘HS\BOB1’ to a Windows account name – (DS_NAME_ERROR_DOMAIN_ONLY) Callstack: at Microsoft.Office.Server.Utilities.WindowsSecurity.TranslateUserName(String name, DS_NAME_FORMAT formatOffered, DS_NAME_FORMAT formatDesired) at Microsoft.Office.Server.UserProfiles.Helpers.GetSidHistory(String strAccountName) at Microsoft.Office.Server.UserProfiles.Helpers.IsSidInSidHistory(String strAccountName, Byte[] bOldSid) at Microsoft.Office.Server.Administration.AccountMigrationManager.MigrateAccount(Guid partitionId, UserProfileApplication userProfileApplication, String strOldAccountName, String strNewAccountName, Boolean bEnforceSidHistory)

Lösung

Glücklicherweise gibt es einen Schalter, der den SidHistory check umgeht.

  • stsadm -o migrateuser -oldlogin HSD\Bob1 -newlogin HS\Bob -ignoresidhistory
  • Move-SPUser -Identity “HSD\Bob1” -NewAlias “HS\Bob” -ignoresidhistory
[Update]Windows PowerShell Command Builder

[Update]Windows PowerShell Command Builder

——————-Update vom 10.11.2012————————

Windows PowerShell Command Builder

Pünktlich zur SharePoint Konferenz 2012 in Las Vegas wurde der Windows PowerShell for SharePoint Command Builder mit neuen Funktionen aufgefrischt

 

In der Produktauswahl stehen uns jetzt  Cmldlets für SharePoint 2013 zur Verfügung.

Besonders hilfreich sind in meinen Augen die Quick Steps.

Die Quick Steps sind die Geläufigsten Befehlskombinationen, die wir bei der täglichen Arbeit verwenden.

Folgende Quick Steps stehen zur Verfügung:

  • Activate a feature across all sites for a Web application
  • Create a site
  • Move all sites from one content database to another
  • Create a site in a specific content database
  • Backup a site
  • Delete a site
  • Return all Webs in all Sites
  • Add a user to a domain.group
  • Remove a user from a domain-group
  • Delete a Content Database

———————————–End Update —————————————-

 

Die PowerShell ist für SharePoint 2010 und/oder Office 365 Administratoren eines der mächtigsten und beliebtesten Werkzeuge.

Leider besteht die Herausforderung allein schon darin, die vielen Cmdlets mitsamt den richtigen Parametern in Verbindung zu bringen, geschweige denn alle Verb-nomen Kombinationen im Kopf zu behalten.

Es gibt ein super Online Werkzeug, dass uns genau darin unterstützt. Es nennt sich Windows PowerShell Command Builder.

 

Mit dem Windows PowerShell Command Builder kann man sich seine Kommandos per Drag & Drop zurechtlegen und je nach Kommando haben wir die Möglichkeit erforderliche oder optionale Parameter einzugeben.

Am Ende erhalten wir das Kommando mitsamt TechNet link zur weiteren Recherche.

%d bloggers like this: