Mit PowerShell Eigenschaften einer Assembly (DLL) aus dem GAC auslesen

Herausforderung: Wie liest man eigentlich mit PowerShell Eigenschaften einer Assembly (DLL) aus dem Global-Assembly-Cache (GAC) aus?

Über den Spezial-Ordner "c:\windows\assembly" gelangt man zum sogenannten Global Assembly Cache (GAC).

Detail-Informationen der Assembly Microsoft.SharePoint.dll aus dem GAC

Hintergrundwissen: Schaut man sich die im GAC befindlichen Assemblies mittels Windows-Explorer an, so wird man schnell zu der Überzeugung gelangen, dass dies ein besonderer Dateiordner ist. Die Ansicht wird mittels dem “Assembly Cache Viewer” dargestellt, wodurch die physische Verzeichnisstruktur verborgen wird. So liegt bspw. die Assembly “Microsoft.SharePoint.dll” im Verzeichnis

C:\Windows\assembly\GAC_MSIL\Microsoft.SharePoint\14.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.dll

Diesen Dateipfad kann man nun aber nicht einfach in die Adressleiste des Windows-Explorer kopieren (der “Assembly Cache Viewer” zeigt dann wieder die Standard-Sicht an). Nutzt man aber Shell-basierte Skriptsprachen wie PowerShell, dann lässt sich schon einiges mit einer Assembly machen.

Wie kopiert man Dateien aus dem GAC heraus? Mit Hilfe des physischen Pfades können die Assemblies des GAC herauskopiert werden. Bspw. wird die Assembly Microsoft.SharePoint.dll wie folgt aus dem GAC kopiert.

Get-ChildItem “C:\Windows\Assembly” -Recurse -Filter “Microsoft.SharePoint.dll” | foreach { copy $_.FullName C:\_tmp\gac }

Wie liest man Eigenschaften einer Assembly aus? Hierzu nutzt man am besten System.Reflection. Mit Hilfe von 4 Kern-Eigenschaften einer Assembly lassen sich alle weiteren Eigenschaften auslesen.

[String]$assInfo = [String]::Format(“{0},Version={1},Culture={2},PublicKeyToken={3}”, $AssemblyNameWithoutExtension, $AssemblyVersion, $AssemblyCulture, $AssemblyPublicKeyToken);

[System.Reflection.Assembly]$ass = [System.Reflection.Assembly]::Load($assInfo);

Der Kommentar lässt sich bspw. wie folgt auslesen:

[System.Diagnostics.FileVersionInfo]::GetVersionInfo($ass.Location).Comments

Die Information der physischen Dateiablage ist hier gespeichert:

$ass.Location

Weitere Attribute lassen sich über spezielle Assembly-Attribut-Klassen auslesen. Bspw. das Copyright-Attribut:

[System.Reflection.AssemblyCopyrightAttribute]$attrCopyright = $ass.GetCustomAttributes([System.Type]::GetType(“System.Reflection.AssemblyCopyrightAttribute”), $false)[0];

$attrCopyright.Copyright

In einem Beispiel-Skript sieht das dann bspw. so aus.

Am Beispiel der Assembly "Microsoft.SharePoint.dll" werden die Eigenschaften mittels PowerShell ausgelesen.

Eigenschaften einer Assembly im GAC mittels PowerShell prüfen

Mehrwert: Mittels eines PowerShell-Skriptes lassen sich alle Eigenschaften von Assemblies auslesen. Damit eignet sich PowerShell, um den Zustand des GACs zu kontrollieren. Bspw. könnte man regelmäßig prüfen, welche Assemblies im GAC vorhanden sind (aktuell installierte Version einer eigenen Lösung checken) und ggf. automatisiert Maßnahmen ergreifen (Email senden).

Veröffentlicht unter Microsoft, SharePoint 2010, SharePoint 2013 | Verschlagwortet mit , , , , | 3 Kommentare

SharePoint 2010 & ILM Certificate could not be created (Event-ID 234)

Was ist passiert? Ein nicht gestarteter SharePoint-Dienst “User Profile Synchronization Service” sollte gestaret werden, um nachfolgend die Profil-Synchronisation zu prüfen. Beim Ausführen der Profil-Synchronisation erschien allerdings eine allgemeine Fehlermeldung.

Starten einer Profil-Synchronisation über die Zentraladministration im SharePoint 2010.

Starten der Profil-Synchronisation innerhalb der UserProfile-ServiceApplication

Ursachenforschung: Beim Starten des SharePoint-Dienstes “User Profile Synchronization Service” wird im Windows-Event-Log (Application) der folgende Eintrag mit der Event-ID 234 (Warnung) geloggt:

Quelle: ILM Web Service Configuration

Beschreibung: ILM Certificate could not be created: Cert step 2 could not be created: D:\Program Files\Microsoft Office Servers\14.0\Tools\MakeCert.exe -pe -sr LocalMachine -ss My -a sha1 -n CN=”ForefrontIdentityManager” -sky exchange -pe -in “ForefrontIdentityManager” -ir localmachine -is root

Nachfolgend sieht man außerdem folgende Windows-Event-Log-Einträge:

ILM Certificate could not be created: netsh http error:netsh http add urlacl url=http://+:5725/ user=testad\mssfarm sddl=D:(A;;GA;;;S-1-5-21-682003330-1604221776-725345543-41150)

ILM Certificate could not be created: netsh http error:netsh http add urlacl url=http://+:5726/ user=testad\mssfarm sddl=D:(A;;GA;;;S-1-5-21-682003330-1604221776-725345543-41150)

Soweit scheint dies ja nicht weiter wild zu sein – es handelt sich ja nur um Warnungen. Interessant sind aber zwei Details:

  1. ILM & ForefrontIdentityManager > Da gab es doch auch zwei Windows-Dienste sowie zugehörige lokale Zertifikate, die man sicherheitshalber beim Erstellern einer User-Profile-ServiceApplication entfernen sollte.
  2. Die Installation ist auf der Partition “D” installiert. > Da gibt es doch immer mal wieder Probleme, insbesondere, wenn man den Configuration-Wizard (PSConfig) durchlaufen lässt, welcher bspw. Berechtigungen auf File-Ebene neu setzt.

Das eigentliche Problem wurde aber erst offensichtlich, als die Profil-Synchronisation über die Zentraladministration gestartet werden sollte (s. Abbildung oben). Im zugehörigen ULS-Log gab es hierzu Einträge ala System.IO.FileLoadException … Microsoft.SharePoint.Portal.UserProfiles.AdminUI.SyncNow.OnPreRender… Das schien die Ursache des Nicht-Funktionierens zu sein.

Lösung: Prüfen, ob die FIM-Windows-Dienste gestartet sind und einen IIS-Reset durchführen.

 

 

Veröffentlicht unter Microsoft, SharePoint 2010 | Verschlagwortet mit , | Hinterlasse einen Kommentar

SharePoint 2010 & Office Web Apps & Could not find stored procedure ‘dbo.proc_LogChange’

Problem: Das Umziehen der Office-Web-Apps Inhalte in eine extra Datenbank (vgl. Technet-Anleitung) konnte nicht durchgeführt werden. Die Konsolenausgabe sagt Folgendes:

Die gespeicherte Prozedur ‘dbo.proc_LogChange’ wurde nicht gefunden.

Und das ULS-Log meinte dies:

System.Data.SqlClient.SqlException: Die gespeicherte Prozedur ‘dbo.proc_LogChange’ wurde nicht gefunden. … Critical    Unknown SQL Exception 2812 occurred. Additional error information from SQL Server is included below.  Die gespeicherte Prozedur ‘dbo.proc_LogChange’ wurde nicht gefunden. … ConnectionString: ‘Data Source=DBAlias2010;Initial Catalog=Mss2010_WSS_Content_WebApp1_OwaCache; …

Ursache: Ich hatte das PowerShell ausgeführt und gleich wieder gestoppt, weil ich es noch modifizieren wollte. Da das PowerShell Cmdlet “New-SPContentDatabase” keine Fortschrittsangaben ausgab, habe ich nicht bemerkt, dass die Datenbank schon erstellt wurde (wie man im ULS-Log sieht, wurde der Name der DB schon genannt) – allerdings nicht komplett (die oben genannte StoredProcedure “proc_LogChange” fehlte bspw. noch). Alle nachfolgenden Aufrufe des PowerShell-Skriptes riefen dann den besagten Fehler hervor.

Lösung: Die bereits erstellte OWA-Datenbank war über die Zentraladministration nicht sichtbar (kein zusätzliche zur WebApplication zugehörige OWA-Inhalts-Datenbank vorhanden). Also konnte ich einfach die Datenbank über das SQL-Management-Studio entfernen. Danach lief das PowerShell-Skript wunderbar.

Veröffentlicht unter Microsoft, SharePoint 2010 | Verschlagwortet mit , , , | Hinterlasse einen Kommentar

IIS-AppPool-Account hat nicht genügend Berechtigungen für User-Profile-Datenbanken

Mein heutiges Problem: Das Erstellen von SharePoint-WebApplications mündet darin, dass der nachfolgende Aufruf mittels Browser einen Fehler wirft.

Nach dem Anlegen einer SharePoint-WebApplication wird dieser Fehler im Browser ausgegeben.

Ein unerwarteter Fehler ist aufgetreten.

Ursachen-Forschung: Das Auffinden der Fehlersuche ist nicht einfach, denn es gibt keine Windows-Event-Log-Einträge und nur den folgenden ULS-Log-Hinweis:

System.Data.SqlClient.SqlException: Die von der Anmeldung angeforderte Mss2010_ProfileDB-Datenbank kann nicht geöffnet werden. Fehler bei der Anmeldung.  Fehler bei der Anmeldung für den Benutzer ‘testad\MssWebAppAdm1

Es fehlt also dem IIS-Application-Pool-Account meiner neu angelegten SharePoint WebApplication eine (oder wahrscheinlich mehrere) Berechtigungen auf Datenbank-Ebene. Der erste Ansatz ist also, die oben genannte fehlende Berechtigung zum Anmelden an einer der drei Datenbanken (Profile, Social und Sync) der User-Profile-ServiceApplication zu untersuchen.

Aber halt (einen Schritt zurück): Welche Berechtigungen benötigt eigentlich ein IIS-Application-Pool-Account einer SharePoint-WebApplication? – Die Antwort ist in Technet-Artikel “Account permission and security settings (SharePoint 2010)” zu finden. Die Quintessenz des Artikels lautet: Die lokalen Berechtigungen und die Datenbankberechtigungen werden automatisch vergeben.

Na gut – offensichtlich ist dem heute bei mir nicht so, denn ich erhalte ja den oben beschriebenen Fehler.

Ein Blick via Sql-Management-Studio auf die Datenbank-Berechtigungen des IIS-Application-Pool-Accounts zeigt, dass der Account tatsächlich keine Berechtigungen für die Profile-DB (und auch nicht auf die anderen beiden Datenbanken Social und Sync) besitzt.

Lösung / Workaround: Da die Berechtigungen von SharePoint selbst vergeben werden (s. Technet-Artikel oben), sollte das Erstellen einer neuen SharePoint-WebApplication samt SiteCollection die erforderlichen Berechtigungen “gradeziehen”.

Um ganz sicher zu gehen, dass ich eine saubere Ausgangsposition habe, habe ich

  1. den Configuration Wizard (PSConfig.exe) mit folgendem Befehl ausgeführt PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures
  2. den Configuration Wizard (PSConfigUI.exe) ausgeführt
  3. eine neue SharePoint-WebApplication mit neuer URL, neuem IIS-ApplicationPool aber gleichen AD-Account (den, der in der ULS-Fehlermeldung oben genannt wurde) und der Angabe neuer Inhalts-Datenbanken und nachfolgend
  4. eine zugehörige SiteCollection erstellt.

Siehe da: Der Aufruf der beider SharePoint-WebApplications im Browser funktioniert wieder. D.h., die Datenbank-Berechtigungen wurden anscheined korrekt nachgezogen. Die für diesen zweck angelegte zweite WebApplication kann nun wieder gelöscht werden (auf Datenbank-Seite werden die Berechtigungen nicht wieder entfernt – zum Glück).

Was nun konkret die Ursache für das initiale Nicht-Setzen der Datenbank-Berechtigungen war, kann ich allerdings nicht sagen. Naja – ein Workaround ist besser als gar nichts.

Veröffentlicht unter Microsoft, SharePoint 2010 | Verschlagwortet mit , , , , , | Hinterlasse einen Kommentar

SharePoint Wiki-Seiten mit Umlauten und der IIS-Isapi-Filter UrlScan

Heute hatte ich das Problem zu lösen, dass sich innerhalb einer SharePoint 2007-Umgebung existierende SharePoint-Wiki-Seiten, die Sonderzeichen enthielten (in meinem Fall war es konkret der deutsche Umlaute “ä”), nicht öffnen ließen.

Die SharePoint-Wiki-Seite "Test äbc" soll aufgerufen (geklickt) werden.

Aufruf einer SharePoint-Wiki-Seite, die ein "ä" enthält.

Der IIS quittiert die Anfrage mit 404.

Die SharePoint-Wiki-Seite mit dem "ä" kann nicht aufgerufen werden - der HTTP-Response wird mit 404 quittiert.

Die Ursache war, dass der IIS-Isapi-Filter “UrlScan” den HTTP-Request blockierte. In den IIS-Logs las sich das wie folgt:

2012-09-10 08:23:25 ... GET /Rejected-By-UrlScan ~/WikiTest/Test%20%C3%A4bc.aspx ...

OK. Es ist also der Isapi-Filter UrlScan. Zu finden ist dieser in “Internet Information Services (IIS) Manager”.

Über den IIS-Manager lässt sich herausfinden, wo der Isapi-Filter UrlScan lokal liegt.

Isapi-Filter "UrlScan" innerhalb des IIS

Anpassungen für diesen Isapi-Filter können über die Konfigurationsdatei “UrlScan.ini” vorgenommen werden.

In der Konfigurationsdatei "UrlScan.ini" können verschiedene Konfigurationen angepasst werden.

UrsScan besitzt eine Konfigurationsdatei "UrlScan.ini"

In meinem speziellen Fall, möchte ich, dass der deutsche Umlaut “ä” nicht blockiert wird. Dazu ändere ich “AllowHighBitCharacters” von dem Wert “0″ auf “1″ an.

Der Wert muss von "0" auf "1" geändert werden. Dann werden auch die deutschen Umlaute nicht blockiert.

Anpassung von "AllowHighBitCharacters" innerhalb von "UrlScan.ini", so dass Sonderzeichen erlaubt werden.

Dann speichere ich die Änderungen in “UrlScan.ini” und die neuen Regeln des Isapi-Filters greifen sofort. Ein erneuter Aufruf meiner zuvor nicht aufrufbaren Url zeigt nun das korrekte Ergebnis.

Nach der Konfigurationsanpassung blockiert UrlScan meine Umlaut-Url nicht mehr. Der IIS quittiert mit dem HTTP-Status 200.

SharePoint-Wiki-Seite (mit Umlaut "ä" in Url) lässt sich nun problemlos laden (HTTP-Response 200)

Fazit: Mit dem IIS-Isapi-Filter UrlScan sowie seinen Konfigurations-Parametern sollte man sich genau beschäftigen, bevor man ihn einsetzt.

 

 

Veröffentlicht unter Microsoft, SharePoint 2007 | Verschlagwortet mit , , , , | 2 Kommentare

Neue PowerShell-Cmdlets in SharePoint 2013

Die Preview-Version von SharePoint 2013 ist ja bereits seit einigen Tagen verfügbar und die zahlreichen Blog-Beiträge dazu sind sehr interessant. Immer wieder liest man dabei, dass einige neue Features nur mittels PowerShell administrierbar sind (bspw. beim Thema “Licensing” – gelesen bei Spencer Harbar) was mich zur Frage führt, welche SharePoint-Cmdlets im Vergleich zur 201oer-Version neu bzw. nicht mehr vorhanden sind.

Eine Übersicht aller 711 Cmdlets für SharePoint 2013 (Preview) kann man auf den Technet-Seiten nachschlagen.

Interessant sind aber auch die SharePoint-Cmdlets, die nur in SharePoint 2010 bzw. nur in SharePoint 2013 verfügbar sind. Bspw. haben die Macher von AutoSPInstaller nicht schlecht gestaunt, dass sich doch mehr SharePoint-Cmdlets geändert haben, als gedacht.

Vorgehen zur Ermittlung neuer und alter SharePoint-Cmdlets

Eine vorgefertigte Übersicht aller neuen oder nicht mehr vorhandenen SharePoint-Cmdlets habe ich leider nicht gefunden. Deshalb habe ich durch folgendes Vorgehen selbst eine Übersicht erstellt.

  1. 2010: Ich habe alle PowerShell-Cmdlets in eine Datei geschrieben (SharePoint 2010 mit SP1 + CU 06/2012).

    Get-Command | ? {$_.CommandType -eq “Cmdlet”} | ? {$_.ModuleName -eq “Microsoft.SharePoint.PowerShell”} | select Name | Out-File “ps-cmdlets-2010.txt”

    Hinweis: Die Anzahl der Cmdlets unterscheidet sich je nach installiertem Update. Bspw. gab es vor SP1 noch 557 SharePoint-Cmdlets. Beim aktuellen Patch-Stand (SP1 + CU 06/2012) gibt es hingegen nur 545 SharePoint-Cmdlets.

  2. 2013: Ich  habe alle PowerShell-Cmdlets in eine Datei geschrieben (SharePoint 2013 Preview).

    Get-Command | ? {$_.Capability -eq “Cmdlet”} | ? {$_.ModuleName -eq “Microsoft.SharePoint.PowerShell”} | select Name | Out-File “ps-cmdlets-2013.txt”

    Hinweis: Interessant hierbei ist der Unterschied der Eigenschaft zum Abfragen, ob es sich um ein Cmdlet handelt. Bei der 2010-Umgebung hieß es noch “CommandType” nun heißt es bei der 2013-Umgebung “Capability”.

  3. Die Inhalte der Dateien, welche SharePoint-Cmdlets entsprechen, habe ich dann mittels eines kleinen PowerShell-Skriptes verglichen und die Ergebnisse ausgegeben. (Der Quellcode des Skriptes ist nicht spektakulär und auch nicht hübsch, deshalb veröffentliche ich ihn mal nicht. Bei Interesse bitte einfach mal anfragen.)

Ergebnis I: In SharePoint 2010 bekannte, aber von SharePoint 2013 (Preview) nicht mehr unterstützte SharePoint-Cmdlets (29).

  • Get-SPClaimTypeEncoding
  • Get-SPEnterpriseSearchExtendedClickThroughExtractorJobDefinition
  • Get-SPEnterpriseSearchIndexPartition
  • Get-SPEnterpriseSearchPropertyDatabase
  • Get-SPEnterpriseSearchQueryComponent
  • Get-SPEnterpriseSearchQueryTopology
  • Get-SPPerformancePointSecureDataValues
  • Get-SPWebAnalyticsServiceApplication
  • Get-SPWebAnalyticsServiceApplicationProxy
  • New-SPClaimTypeEncoding
  • New-SPEnterpriseSearchMetadataCategory
  • New-SPEnterpriseSearchPropertyDatabase
  • New-SPEnterpriseSearchQueryComponent
  • New-SPEnterpriseSearchQueryTopology
  • New-SPWebAnalyticsServiceApplication
  • New-SPWebAnalyticsServiceApplicationProxy
  • Ping-SPEnterpriseSearchContentService
  • Remove-SPActivityFeedItems
  • Remove-SPEnterpriseSearchMetadataCategory
  • Remove-SPEnterpriseSearchPropertyDatabase
  • Remove-SPEnterpriseSearchQueryComponent
  • Remove-SPEnterpriseSearchQueryTopology
  • Restart-SPEnterpriseSearchQueryComponent
  • Set-SPEnterpriseSearchIndexPartition
  • Set-SPEnterpriseSearchPropertyDatabase
  • Set-SPEnterpriseSearchQueryComponent
  • Set-SPEnterpriseSearchQueryTopology
  • Set-SPWebAnalyticsServiceApplication
  • Set-SPWebAnalyticsServiceApplicationProxy

Ergebnis II: In SharePoint 2013 (Preview) neu hinzugefügte SharePoint-Cmdlets (194).

  • Add-ScaleOutDatabase
  • Add-SPRoutingMachineInfo
  • Add-SPRoutingMachinePool
  • Add-SPRoutingRule
  • Add-SPScaleOutDatabase
  • Add-SPSocialAppPermissions
  • Add-SPThrottlingRule
  • Add-SPUserLicenseMapping
  • Add-SPWOPISuppressionSetting
  • Backup-SearchServiceApplicationIndex
  • Clear-ScaleOutDatabaseDeletedDataSubRange
  • Clear-ScaleOutDatabaseLog
  • Clear-ScaleOutDatabaseTenantData
  • Clear-SPScaleOutDatabaseDeletedDataSubRange
  • Clear-SPScaleOutDatabaseLog
  • Clear-SPScaleOutDatabaseTenantData
  • Convert-SPWebApplication
  • Copy-LocalActivitiesToExternalHost
  • Copy-SPSite
  • Disable-SPUserLicensing
  • Enable-SPUserLicensing
  • Export-ScaleOutDatabaseTenantData
  • Export-SPAppPackage
  • Export-SPPerformancePointContent
  • Export-SPScaleOutDatabaseTenantData
  • Extend-ScaleOutDatabaseDataRange
  • Extend-SPScaleOutDatabaseDataRange
  • Get-EduConfigSettings
  • Get-ExternalHostApplicationProxy
  • Get-ScaleOutDatabase
  • Get-ScaleOutDatabaseDataState
  • Get-ScaleOutDatabaseInconsistency
  • Get-ScaleOutDatabaseLogEntry
  • Get-SearchServiceApplicationStores
  • Get-SPAccessServicesApplication
  • Get-SPAccessServicesDatabase
  • Get-SPAccessServicesDatabaseServer
  • Get-SPAccessServicesDatabaseServerGroup
  • Get-SPAccessServicesDatabaseServerGroupMapping
  • Get-SPAppInstance
  • Get-SPAppStateDisableListSync
  • Get-SPAppStateLastSyncTime
  • Get-SPAppStateUpdateInterval
  • Get-SPAuthenticationRealm
  • Get-SPBingMapsDisplayInAllLocales
  • Get-SPBingMapsKey
  • Get-SPDistributedCacheClusterInfoManager
  • Get-SPEnterpriseSearchComponent
  • Get-SPEnterpriseSearchCrawlLogReadPermission
  • Get-SPEnterpriseSearchFileFormat
  • Get-SPEnterpriseSearchLinksDatabase
  • Get-SPEnterpriseSearchOwner
  • Get-SPEnterpriseSearchQuerySpellingCorrection
  • Get-SPEnterpriseSearchResultItemType
  • Get-SPEnterpriseSearchTopology
  • Get-SPExcelBIServer
  • Get-SPIRMSettings
  • Get-SPRequestManagementSettings
  • Get-SPRoutingMachineInfo
  • Get-SPRoutingMachinePool
  • Get-SPRoutingRule
  • Get-SPScaleOutDatabase
  • Get-SPScaleOutDatabaseDataState
  • Get-SPScaleOutDatabaseInconsistency
  • Get-SPScaleOutDatabaseLogEntry
  • Get-SPSiteSubscriptionIRMConfig
  • Get-SPSiteUpgradeSession
  • Get-SPSiteURL
  • Get-SPThrottlingRule
  • Get-SPTrustedSecurityTokenService
  • Get-SPUserLicense
  • Get-SPUserLicenseMapping
  • Get-SPUserLicensing
  • Get-SPUserSettingsProvider
  • Get-SPUserSettingsProviderManager
  • Get-SPWOPIBinding
  • Get-SPWOPISuppressionSetting
  • Get-SPWOPIZone
  • Get-TranslationThrottlingSettings
  • Import-ScaleOutDatabaseTenantData
  • Import-SPAppPackage
  • Import-SPEnterpriseSearchCustomExtractionDictionary
  • Import-SPEnterpriseSearchThesaurus
  • Import-SPPerformancePointContent
  • Import-SPScaleOutDatabaseTenantData
  • Install-SPApp
  • Install-SPEduSites
  • Move-SPDeletedSite
  • New-ExternalHostApplicationProxy
  • New-SPAccessServicesApplication
  • New-SPAccessServicesDatabaseServer
  • New-SPAppManagementServiceApplication
  • New-SPAppManagementServiceApplicationProxy
  • New-SPAzureAccessControlServiceApplicationProxy
  • New-SPBECWebServiceApplicationProxy
  • New-SPEnterpriseSearchAdminComponent
  • New-SPEnterpriseSearchAnalyticsProcessingComponent
  • New-SPEnterpriseSearchContentProcessingComponent
  • New-SPEnterpriseSearchFileFormat
  • New-SPEnterpriseSearchIndexComponent
  • New-SPEnterpriseSearchLinksDatabase
  • New-SPEnterpriseSearchQueryProcessingComponent
  • New-SPEnterpriseSearchResultItemType
  • New-SPEnterpriseSearchTopology
  • New-SPExcelBIServer
  • New-SPPowerPointConversionServiceApplication
  • New-SPPowerPointConversionServiceApplicationProxy
  • New-SPRequestManagementRuleCriteria
  • New-SPTranslationServiceApplication
  • New-SPTranslationServiceApplicationProxy
  • New-SPTrustedSecurityTokenService
  • New-SPUserSettingsProvider
  • New-SPWOPIBinding
  • New-SPWorkManagementServiceApplication
  • New-SPWorkManagementServiceApplicationProxy
  • Remove-ScaleOutDatabase
  • Remove-SPAccessServicesDatabaseServer
  • Remove-SPEnterpriseSearchComponent
  • Remove-SPEnterpriseSearchCrawlLogReadPermission
  • Remove-SPEnterpriseSearchFileFormat
  • Remove-SPEnterpriseSearchLinksDatabase
  • Remove-SPEnterpriseSearchResultItemType
  • Remove-SPEnterpriseSearchServiceApplicationSiteSettings
  • Remove-SPEnterpriseSearchTenantSchema
  • Remove-SPEnterpriseSearchTopology
  • Remove-SPExcelBIServer
  • Remove-SPRoutingMachineInfo
  • Remove-SPRoutingMachinePool
  • Remove-SPRoutingRule
  • Remove-SPScaleOutDatabase
  • Remove-SPSiteUpgradeSession
  • Remove-SPSiteURL
  • Remove-SPSocialAppPermissions
  • Remove-SPThrottlingRule
  • Remove-SPTranslationServiceJobHistory
  • Remove-SPTrustedSecurityTokenService
  • Remove-SPUserLicenseMapping
  • Remove-SPUserSettingsProvider
  • Remove-SPWOPIBinding
  • Remove-SPWOPISuppressionSetting
  • Repair-SPSite
  • Repartition-SPEnterpriseSearchLinksDatabases
  • Request-SPUpgradeEvaluationSite
  • Reset-SPAccessServicesDatabasePassword
  • Restart-SPAppInstanceJobs
  • Restore-SearchServiceApplicationIndex
  • Set-EduConfigSetting
  • Set-ScaleOutDatabaseDataSubRange
  • Set-SPAccessServicesApplication
  • Set-SPAccessServicesDatabaseServer
  • Set-SPAccessServicesDatabaseServerGroupMapping
  • Set-SPAppManagementDeploymentId
  • Set-SPAppStateDisableListSync
  • Set-SPAppStateUpdateInterval
  • Set-SPAuthenticationRealm
  • Set-SPBingMapsDisplayInAllLocales
  • Set-SPBingMapsKey
  • Set-SPDistributedCacheClusterInfoManager
  • Set-SPEnterpriseSearchCrawlLogReadPermission
  • Set-SPEnterpriseSearchLinksDatabase
  • Set-SPEnterpriseSearchQuerySpellingCorrection
  • Set-SPEnterpriseSearchResultItemType
  • Set-SPEnterpriseSearchTopology
  • Set-SPExcelBIServer
  • Set-SPIRMSettings
  • Set-SPPowerPointConversionServiceApplication
  • Set-SPRequestManagementSettings
  • Set-SPRoutingMachineInfo
  • Set-SPRoutingMachinePool
  • Set-SPRoutingRule
  • Set-SPScaleOutDatabaseDataSubRange
  • Set-SPSiteSubscriptionIRMConfig
  • Set-SPSiteURL
  • Set-SPThrottlingRule
  • Set-SPTranslationServiceApplication
  • Set-SPTranslationServiceApplicationProxy
  • Set-SPTrustedSecurityTokenService
  • Set-SPWOPIBinding
  • Set-SPWOPIZone
  • Set-SPWorkManagementServiceApplication
  • Set-SPWorkManagementServiceApplicationProxy
  • Set-TranslationThrottlingSettings
  • Split-ScaleOutDatabase
  • Split-SPScaleOutDatabase
  • Start-BulkOperation
  • Test-SPSite
  • Uninstall-SPAppInstance
  • Update-SPAppCatalogSettings
  • Update-SPAppInstance
  • Update-SPMicroblogFeedCache
  • Update-SPMicroblogLMTCache
  • Upgrade-SPEnterpriseSearchServiceApplicationSiteSettings
  • Upgrade-SPFarm
  • Upgrade-SPSite

Fazit

Die weniger gute Nachricht vorweg: Es gibt 29 nicht mehr zur Verfügung stehende Cmdlets. Für diese sollte geprüft werden, ob sie in PowerShell-Skripten verwendet werden, die voraussichtlich auch auf SharePoint 2013-Umgebungen zum Einsatz kommen sollen.

Die gute Nachricht zuletzt: Für die von mir untersuchten Umgebungen gibt es noch 517 SharePoint-Cmdlets die rein von der Benamung gleich geblieben sind (die Parameter als auch die Funktionsweise kann sich trotzdem geändert haben). Außerdem gibt es 194 neue spannende Cmdlets (SPRoutingMachineInfo, SPUserLicense, SPBingMaps, SPDistributedCacheCluster, SPTranslationService, SPApp, SPAzure, BulkOperation, SPMicroblog),  die sicherlich einen Teil der entfallenen Cmdlets wiedergutmachen. ;-)

 

 

Veröffentlicht unter Microsoft, SharePoint 2010, SharePoint 2013 | Verschlagwortet mit , , , | Hinterlasse einen Kommentar

Stärken und Schwächen von SharePoint 2010

Gefühlt gibt es kaum Menschen, die mit ihrem SharePoint 2010 zufrieden sind. Aber woran machen sie das nur fest? Wurde ihnen zuviel versprochen? Aus welchem Blickwinkel hat sich ihre Meinung manifestiert? – Meiner Meinung nach sollten bei dem Versuch der Beantwortung nicht nur die vermeintlichen Schwächen eines SharePoint 2010 berücksichtigt werden. Auch die etwas gröbere Sichtweise (High-Level-Sicht), was denn ein SharePoint 2010 überhaupt ist und was dessen Funktionsumfang und deren besondere Stärken sind müssen in die Betrachtung einfließen.

Was ist SharePoint 2010?

Die interessanteste Frage überhaupt kann man gut mit einem historischen Rückblick beantworten, denn die Produktnamen der SharePoint-Versionen 2001, 2003, 2007 und 2010 haben sich im Laufe der Zeit geändert.

Alle Produktlogos beinhalten den Produktnamen, welcher sich im Laufe der vier bisherigen Versionen geändert hat.

Die Produktlogos der SharePoint Versionen 2001, 2003, 2007 und 2010.

Die ersten beiden Versionen beinhalteten das Wort “Portal”, was laut Wikipedia ein Anwendungssystem bezeichnet, “das sich durch die Integration von Anwendungen, Prozessen und Diensten auszeichnet. Ein Portal stellt seinem Benutzer unterschiedliche Funktionen zur Verfügung, wie beispielsweise Personalisierung, Sicherheit, Navigation und Benutzerverwaltung.” (Quelle: Wikipedia, 28.06.2012)

Seit dem Jahr 2002 ist SharePoint ein Teil von Microsofts Produktstrategie. Von daher wundert es nicht, dass in der dritten Version das Wort “Portal” durch “Office” ersetzt wurde, was die tiefe Integration der eigenen Office-Produkte (Outlook, Word,…) hervgehoben hat.

Microsoft selbst sagt immer gern, dass SharePoint ihr am schnellsten wachsendes Server-Produkt ist. Vom Erfolg getrieben, benötigt die akutelle Version SharePoint 2010 keine beschreibenden Worte mehr. Jeder kennt den Produktnamen. (Aus Marketingsicht wurde also alles richtig gemacht. ;-))

Und es gibt sehr viele Firmen, die SharePoint im Einsatz haben (es wird von Prozentzahlen zwischen 30-50% gemunkelt). Allerdings wird der Funktionsumfang nur selten erfasst. Gartner bspw. zählt SharePoint 2010 zu den Top 3 ECM-Systemen (auch wenn das nur ein Teil des Funktionsumfanges ist). Auch die Real Story Group hat Einordnungsprobleme und spendiert SharePoint einen eigenen Hauptmenüpunkt – wohlgemerkt neben allgemeinen Fachbegriffen wie Web CMS, DMS, Portalen, Collaboration und Suche.

Nicht nur Real Story Group hat Einordnungsprobleme. SharePoint ist überall.

SharePoint als eigener Menüpunkt neben Web CMS, ECM, DMS, Portalen, Collaboration und Search (Quelle: realstorygroup.com)

Was ist denn nun SharePoint? Ich glaube die beste Beschreibung geben die Marketing-Experten von Microsoft selbst (hier). Es gibt leider keinen Satz, der es gut beschreibt, wobei mir dieser hier noch am besten gefällt: “The Business Collaboration Platform for the Enterprise and the Web”.

Fazit: SharePoint 2010 bringt alles mit, was man heutzutage im Unternehmen benötigt, um eine webbasierte Zusammenarbeit zu ermöglichen. (Der oft genutzte Vergleich mit dem Schweizer Taschenmesser ist an dieser Stelle nicht unangebracht. ;-))

Allerdings (und das ist mein ganz persönlicher Hinweis) kann ein Generalist wie SharePoint nicht mit Spezialisten verglichen werden. Das käme dem Vergleich von Äpfeln mit Birnen gleich.

Was sind die Stärken von SharePoint 2010?

Aus High-Level-Sicht sind die folgenden Punkte als Stärken von SharePoint anzusehen:

  • SharePoint ist Teil von Microsofts Produkt-Strategie. Es werden also nahezu alle Produkte von Microsoft in SharePoint integriert. Ein Beispiel ist die Integration in die Office-Produkte.
  • SharePoint erfüllt alle Anforderungen an ein Portal.
  • SharePoint stellt verschiedene Funktionsstufen und Lizenz-Modelle zur Verfügung. Ob Foundation oder Server, On-Premise oder ein Cloud-Anatz – es gibt viele Möglichkeiten.
  • SharePoint ist eines der führenden ECM-Systeme.
  • SharePoint wird von einer immer größer werdenden Zahl von Unternehmen eingesetzt.
  • SharePoint hat eine starke Community (Blogger, MVPs, CodePlex, Third-Party-Anbieter wie Nintex, K2, AvePoint,…).

Aus der Architektur-Sicht sehe ich folgende Punkte als Vorteile:

  • SharePoint erfüllt Standards (APIs, SOA-Interfaces, Accessability, valid Xhtml 1.0).
  • SharePoint unterstützt verschiedene Authentifizierungs-Mechanismen (Claims-Based Auth).
  • SharePoint ist skalierbar (auch geografisch – hier ein Beispiel).
  • SharePoint-Eigenentwicklungen sind mit Standard-Werkzeugen (Visual Studio, SharePoint-Designer) möglich und beruhen auf Standard-Frameworks (.Net, SharePoint-SDK).

Was sind Punkte, die zu echten Problemen werden können (die Schwächen)?

Aus High-Level-Sicht führen die folgenden Punkte zumeist zu Problemen und sind damit als Schwächen anzusehen:

  • Die Zusammensetzung der Lizenzierungskosten für Server und Nutzer sind nicht trivial.
  • Es wird eine Strategie zur Einführung von SharePoint benötigt. Das inkludiert das Anforderungen, Infrastrukturen, Rollen- und Rechte Berücksichtigung finden müssen.
  • Große SharePoint-Farmen benötigen eine komplexe Infrastruktur. Hierfür werden Experten in den Bereichen Active Directory, Windows-Server-Betriebssysteme, MSSQL-Server, SharePoint-Server, Security, Hardware, Netzwerk, Betrieb, Test,… benötigt.
  • Überbewertung nicht ausgeprägter Stärken. SharePoint ist bspw. kein pures ECMS, DMS, Suchmaschine und es ist auch kein File-Server-Ersatz.
  • Der Einsatz von SharePoint löst nicht unbedingt die bereits existierenden Probleme. Wenn es bspw. Performance-Probleme innerhalb des Netzwerkes gibt, wird dies nicht durch den Einsatz von SharePoint gelöst (im Gegenteil).
  • SharePoint ist pauschal an allem Schuld. Tritt ein Fehler auf, ist die Fehlersuche nicht trivial.

Aus der Architektur-Sicht sehe ich weiterhin folgende Punkte als problematisch:

  • Die Komplexität einer SharePoint-Farm bzw. deren Architektur wird unterschätzt. Ich denke da gern an die Vielzahl von Komponenten die miteinander kommunizieren (AD, DB, Email, SharePoint, Randsysteme,…) oder die Anzahl an Datenbanken die von den WebApplications und ServiceApplications benötigt werden.
  • SharePoint ist skalierbar, besitzt aber Grenzen. Ein unbegrenztes Wachstum ist nicht möglich. Mit einer guten Anforderungsaufnahme sowie der Erstellung einer Informationsarchitektur können viele Höchstwerte zwar zeitlich nach hinten geschoben werden, aber irgendwann werden sie erreicht.
  • Schlecht entworfene Lösungen. Wobei das Problem hat man ja mit jedem Produkt bzw. Technologie.

Um das einleitende Problem eines unzufriedenen SharePoint-Nutzers noch einmal aufzugreifen: Ja es gibt eine ganze Reihe von existierenden Problemen im Zusammenhang mit der Nutzung von SharePoint. Die Ursache einer schlechten Nutzererfahrung ist aber im Detail zu prüfen. – Letztlich kann man es auch aus einer anderen Sichtweise sehen und behaupten: Den Status, dass sich jemand Gedanken um etwas macht und Verbesserungspotentiale identifiziert, muss man sich erst einmal erarbeiten.

Veröffentlicht unter Microsoft, SharePoint 2010 | Verschlagwortet mit | 2 Kommentare

Woran erkennst Du, ob Du ein SharePoint-Profi bist?

Ja irgendwie nennen wir uns ja alle SharePoint-Profi oder SharePoint-Experte oder Senior-SharePoint-Berater oder wie auch immer. Aber unter uns Geeks: Woran man wirklich erkennt, wie stark man geknechtet ist, erkennt man erst, wenn man sich die 10 Punkte “You might be a SharePoint-Professional if…” von Mark Rackley (aka the “The SharePoint Hillbilly“) vor Augen führt.

Veröffentlicht unter Allgemein, Microsoft, SharePoint 2007, SharePoint 2010 | Verschlagwortet mit , , , | 1 Kommentar

SharePoint 2010 & Suche: FullTextSqlQuery mit PowerShell testen

Die Klasse FullTextSqlQuery kann zur Abfrage von SharePoint-Inhalten in einer SharePoint-Komponente (WebPart, FeatureReceiver, Job,…) genutzt werden. Da Fehlerausgaben teilweise recht schwammig sind (ala “An error occured… sender did not specify a reason.”), ergibt sich oft die Frage, wie man die gleiche Such-Abfrage einfach nachstellen kann.

Genau für dieses Fälle (also das Testen oder Nachstellen von Such-Anfragen in Form von Full-Text-Sql-Queries) nutze ich ein PowerShell-Skript, welches auf einem SharePoint-Server ausgeführt werden kann. Als Eingabe wird ein Query-String eingelesen. Das Resultat wird dann direkt auf der PowerShell-Konsole ausgegeben.

Hinweis: Es gibt auch ein paar Codeplex-Projekte, welche sich dem Theme widmen und GUIs hierfür entwickelt haben (vgl. “Search Community Toolkit“). Ich finde diese auch wunderbar, um bspw. die Managed-Search-Properties zu finden, welche ich für den Select-Part einer Search-Query verwenden kann, allerdings habe ich mit den Tools nie Ergebnisse gesehen. Deshalb die Lösung mit dem PowerShell-Skript.

Die Lösung mit dem PowerShell-Skript funktioniert wie folgt:

  1. PowerShell mit SharePoint-Modulen öffnen
  2. PowerShell-Skript aufrufen
  3. Full-Text-Sql-Query eingeben (Syntax s. “SharePoint Search SQL Syntax Reference“)
  4. Resultat ansehen
Mit Hilfe des PowerShell-Skriptes könnten Full-Text-Sql-Queries auf einem SharePoint-Server getestet werden.

FullTextSqlQuery mit dem PowerShell-Skript testen

Und hier noch das PowerShell-Skript (ala Steve P):

$q = read-host “Enter query-text”
$site = get-spsite “http://<YourWebApp-Url>
$kq = new-object Microsoft.Office.Server.Search.Query.FullTextSqlQuery($site)
$kq.ResultTypes= [Microsoft.Office.Server.Search.Query.ResultType]::RelevantResults
$kq.RankingModelId = “D9BFB1A1-9036-4627-83B2-BBD9983AC8A1″
$kq.QueryText = $q
$res = $kq.Execute()
$table = new-object System.Data.DataTable
$table.Load($res[$kq.ResultTypes],[System.Data.LoadOption]::OverwriteChanges)
echo $table

Sicherlich kann man das Skript noch erweitern, um bspw. die WebApp-Url als Eingabeparameter abzufragen, das Limiteren der Anzahl der Ergebniss oder das Highlighten bestimmter Ergebnis-Bestandteile (vgl. PowerShell auf Poshcode)… hier sind keine Grenzen gesetzt.

Viel Spaß beim Suchen!

 

Veröffentlicht unter Microsoft, SharePoint 2010 | Verschlagwortet mit , , , | 1 Kommentar

SharePoint 2010 & Search: UnauthorizedAccessException beim Erstellen einer Crawled-Property / Managed-Property

Beim Erstellen SharePoint-2010-Such-Lösung hatte ich zuletzt die Herausforderung, einige Eingabe- und Auswerte-WebParts für eine Taxonomie-Basierte Suche umzusetzen. Beim Installieren auf einer mir unbekannten SharePoint-Farm gab es allerdings eine Herauausforderung, die sich in folgender ULS-Log-Fehlermeldung verbarg:

System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.     at Microsoft.Office.Server.Search.Query.UserVerification.ThrowIfNotSearchAdmin(SearchServiceApplication searchApp)     at Microsoft.Office.Server.Search.Administration.Schema.QueryCrawledProperties(String filter, Int32 cMaxProps, Guid lastPropset, String lastPropertyName, Boolean forwardDirection)

Während der Aktivierung eines Features sollte eine Crawled-Property und eine Managed-Property erstellt werden (Code ala “Michael Brockmann“). Dabei gibt es folgende Randbedingungen (die mir bis dahin bekannt waren):

  • Der eingeloggte Nutzer muss Administrator der Search-Service-Application sein.
  • Der Nutzer, unter dem der IIS-AppPool der SharePoint-WebApplication läuft benötigt Zugriffsrechte auf der Such-Datenbank der Search-Service-Application (nicht die Crawl-Store-DB und auch nicht die Property-Store-DB).

Diese Bedingungen waren erfüllt und mir war gänzlich schleierhaft, wieso ich keine Rechte hatte, diese Crawled-Property und das Managed-Property anzulegen. Mehr Rechte kann ein SharePoint-Nutzer nicht bekommen… dachte ich.

Die Lösung war letztlich simpel: Es gab zwei Search-Service-Applications und zum Zeitpunkt der Aktivierung des Features, war die WebApplication (auf der das Feature aktiviert werden sollte) mit der falschen Search-Service-Application (einer FAST-Search-Service-Application) verbunden und nicht mit der von mir vorgesehenen Enterprise-Search-Service-Application. Insofern war die Fehlermeldung schon korrekt, denn auf der  FAST-Search-Service-Application hatte mein Nutzer wirklich keine Admin-Rechte. > Das Anpassen der Service-Connections für meine SharePoint-WebApplication behob schließlich den unschönen ThrowIfNotSearchAdmin Fehler.

Veröffentlicht unter Microsoft, SharePoint 2010 | Verschlagwortet mit , , , , | Hinterlasse einen Kommentar