AD-Nutzer mit Hilfe von PowerShell und einer CSV-Datei erstellen

Beim Aufsetzen einer SharePoint-Farm ist eine immer wiederkehrende Aufgabe, Domain-Service-Accounts zu erstellen. Die Anzahl der zu erstellenden Domain-Service-Accounts varriiert dabei von

Die Service-Accounts sind eigentlich recht einfach anzulegen. Aber bei mehr als 3 anzulegenden Service-Accounts, freut sich der AD-Admin als auch der spätere SharePoint-Admin über folgende Eigenschaften der Service-Accounts:

  1. einheitliche Benamung (Vorname, Nachname, DisplayName, LogonName,…)
  2. einheitliches Setzen von Account-Eigenschaften (Password never expires, User is not allowed to change password,…)

Soweit so gut, aber gibt es denn sowas nicht schon? – Nach 2 Minuten Googeln bin ich auf eine Reihe von Lösungen gestoßen, wie man mit Hilfe einer CSV-Datei eine Art Bulk-AD-User-Insert umsetzen kann:

  • CSVDE.exe – Kommandozeilen-Tool, welches aber keine Startpasswörter vergeben kann.
  • PowerShell-Cmdlets – Mittels Standard-Cmdlets Import-CSV und New-ADUser kann das gewünschte Verhalten mit einem Einzeiler umgesetzt werden.
  • PowerShell-Cmdlets von Quest - ActiveRoles Management Shell for Active Directory – Gut dokumentierte Zusatz-Cmdlets (35 MB), die aber installiert werden müssen.
  • AD-Toolset - Active Directory User Import, AD Bulk Users – Lizenzpflichtiges Toolset (teils GUI, teils Kommandozeile), mit dem ein AD Bulk Import durchgeführt werden kann.

Als PowerShell-Verfechter sind für mich nur die beiden PowerShell-Cmdlet-Lösungen von Interesse. Da ich oft keinen Einfluss auf installierte Software auf dem AD-Server habe, scheidet auch die Quest-Lösung für mich aus. Bleibt also nur noch die Einzeiler-Lösung aus Technet. – Leider fand ich diese etwas kryptisch und die Konsolen-Ausgabe eines Bulk-Imports wollte ich auch ein wenig beeinflussen. Deshalb habe ich den Einzeiler um 124 Zeilen erweitert. Das Vorgehen wäre dann das Folgende:

  1. CSV-Datei erstellen
  2. AD-Zielordner wählen (bspw. eine OU)
  3. PowerShell-Skript ausführen (Bulk-AD-User-Import-From-CSV-File)
    1. Parameter 1: InputFile (das ist der Pfad zur CSV-Datei)
    2. Parameter 2: AdDN (das ist der sogenannte Distinguished-Name)
    3. Beispielaufruf: ./Bulk-AD-User-Import-From-CSV-File.ps1 “my-CSV-Input.csv” “OU=ServiceAccountsOU,dc=testad,dc=de”
  4. Änderungen im AD prüfen
  5. Wichtig: Passwörter der angelegten Nutzer ändern (weil das Setzen der Passwörter nicht ordnungsgemäß vom Skript erfüllt wird.

Bebildert sieht es dann so aus:

Die CSV-Datei kann beliebig viele Zeilen enthalten. Wichtig ist, dass die Kopfzeile existiert.

Schritt 1: CSV-Datei erstellen

Im zweiten Schritt wählt man einen AD-Ordner aus, in dem die Service-Accounts erstellt werden sollen.

Schritt 2: AD-Ordner wählen - Hier "ServiceAccountsOU"

Nun wird das PowerShell-Skript mit zwei Parametern aufgerufen, um die AD-Accounts der CSV-Datei anzulegen.

Schritt 3: PowerShell ausführen

Im gewählten AD-Ordner sind (nach einem Refresh der Ansicht) die AD-Accounts aus der CSV-Datei nun enthalten.

Schritt 4: Prüfen, ob die AD-Accounts angelegt wurden.

Der angelegte FarmAdmin-Account besitzt die allgemeinen Eigenschaften (Vorname, Nachname, Anzeigename, Beschreibung und E-Mail).

Schritt 5: Details des angelegten FarmAdmin-Accounts prüfen.

Der angelegte FarmAdmin-Account hat auch befüllte erweiterte Eigenschaften (Anmeldename, Nutzer kann das Passwort nicht ändern, Nutzerpasswort läuft niemals ab, AD-Account läuft niemals ab).

Schritt 6: Erweiterte Details des angelegten FarmAdmins prüfen.

Das PowerShell-Skript berücksichtigt in Symbiose mit der CSV-Datei als Datenquelle natürlich bei weitem (noch) nicht alle theoretisch möglichen Eigenschaften eines AD-Accounts. Jedoch genügt es an dieser Stelle als solide Grundlage, um die Vorbereitung einer SharePoint-Installationen zu automatisieren und Zeit zum Kaffeetrinken zu gewinnen.

Über die Google-Recherche bin ich übrigens noch auf zwei weitere interessante Blog-Beiträge gestoßen:

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

Die SharePoint-Experten sind im Oktober in Berlin und im September online erlebbar

Die European SharePoint Conference findet erstmals seit 2007 wieder statt – und das in Berlin. Das Who-Is-Who der SharePoint-Gilde gibt sich vom 17.-20. Oktober 2011 im Südosten Berlins die Ehre.

Diese SharePoint-Experten halten ihre online seminare (webinare) zum Großteil in der Vorwoche zur European SharePoint Conference.

Webinar week speaker photos (Quelle: www.sharepointeurope.com)

Da muss man eigentlich dabei sein. Wem allerdings die rund 500€ Tagesticket bzw. 950€ für das 3-Tage-Komplett-Programm zuviel sind, hat zwei Möglichkeiten, kostenfrei am Fachwissen zu partizipieren:

  1. Bis zum 9. September hat man die Chance mit etwas Kreativität das 3-Tage-Ticket zu gewinnen.
  2. Anfang September finden eine Reihe von Webinaren statt, die den Teilnehmer lediglich die Zeit für eine Registrierung (und ggf. Telefonkosten) kosten.

Falls mir ein Ticket in die Hände fällt, habe ich schonmal meine persönlichen Favoriten des reichhaltigen und internationalen Konferenz-Programmes aufgelistet:

  • Montag: “Building High-End, Highly Secure SharePoint 2010 Farm-Topologies” > Insbesondere der Zusatz “Plan, implement and maintain high quality SharePoint farms in the real world” lässt die Erwartungshaltung steigen, dass hier viel Praxiserfahrung übermittelt wird. (Oliver Basarke und Wojciech Micka, GER)
  • Dienstag: Hier gibts gleich mehrere interessante Vorträge.
    • SharePoint 2010 Upgrade Best Practices” (Joel Oleson, USA)
    • Why Are We Still Talking About SharePoint Governance?” (Anders Skjoenaa, DK)
    • Best Practices for SharePoint 2010 Search” (Agnes Molnar, HUN)
    • Cutting Costs Using SharePoint 2010” Alan Richards (UK)
  • Mittwoch:
    • Playing in the Sandbox” (Wictor Wilen, SWE)
    • Best Practices for Organizing Documents in SharePoint 2010” (Agnes Molnar, HUN)
    • SharePoint Workspace 2010 – The Offline Client for SharePoint Server 2010” (Hans Brender, GER)
    • Designing Governance: How Information Management and Security Must Drive Your Architecture” (Dan Holme, USA)
    • Optimize, Store and Protect SharePoint 2010 Server…Best Practices” (James Baldwin, IRL)
    • Developing a SharePoint 2010 Service Application” (Paolo Pialorsi, ITA)
  • Donnerstag:
    • The Truth Behind SharePoint Recovert and Availability: Meeting your SLA’S” (Dan Holme, USA)
    • 11 Strategic Considerations for SharePoint Migration” (Christian Buckley, USA)
    • Mobile Applications for SharePoint using HTML5” (Christian Heindel, GER)
    • Advanced SharePoint Solution Architecture & Development” (Radi Atanassov, BGR)
    • Building High Quality Solutions with Design Patterns & Application Foundations for SharePoint 2010” (Christoffer von Sabsay, SWE)
    • Search as a Strategic Platform in your Enterprise” (Frank Robin Danielsen)

Und würde es einen Pokal für den schönsten Titel eines Programmpunktes geben, ich würde ihn Christian Glessner geben: “Mega Mergers – Integrating SharePoint and Azure”. Der Sahl wird brechend voll sein – ich inklusive! ;-))

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

Herrenlose TimerJobs – Operation is not valid due to the current state of the object.

Gestern hatte ich während der Migration einer SharedService-DB einige Male eine UserProfile-ServiceApplication angelegt und gelöscht. Dabei ist mir anscheinend mindestens ein Mal ein Fehler beim Löschen einer UserProfile-ServiceApplication unterlaufen. Das hatte zur Folge, dass diverse TimerJobs nicht sauber liefen. Sogar die Administrationsseite der TimerJobs brachte einen Fehler, der im ULS-Log dann so aussah:

System.InvalidOperationException: Operation is not valid due to the current state of the object.    at Microsoft.Office.Server.Administration.UserProfileApplicationJob.get_UserProfileApplication()…

Nach kurzer Recherche hat sich bewahrheitet, dass wohl noch herrenlose TimerJobs in der Farm herumgeistern. Wie man diese löscht, erklärt Michael Schau ansehnlich in seinem Blog.

Da man die herrenlosen TimerJobs nicht über die Oberfläche entfernen kann (die Seite gab ja einen Fehler), muss man es über PowerShell realisieren.

  1. Alle TimerJobs für die UserProfile-ServiceApplication suchen. Get-SPTimerJob | where {$_.name -match “Mss_Srv_UserProfileServiceApplicationMigrated*”} | format-table name
  2. Den Filter im PowerShell-Skript so setzen, dass nur die “herrenlosen” TimerJobs gefunden werden. Get-SPTimerJob | where {$_.name -match “Mss_Srv_UserProfileServiceApplicationMigrated2*”} | format-table name (bei mir war es die zweite angelegte UserProfile-ServiceApplication, die nicht sauber gelöscht wurde)
  3. PowerShell zum Löschen der gefilterten TimerJobs ausführen Get-SPTimerJob | where {$_.name -match “Mss_Srv_UserProfileServiceApplicationMigrated2*”} | % { $_.Delete()}
  4. Nochmals prüfen, ob die benötigten TimerJobs noch existieren und die herrenlosen gelöscht wurden Get-SPTimerJob | where {$_.name -match “Mss_Srv_UserProfileServiceApplicationMigrated*”} | format-table name

Nach diesen vier Schritten konnte ich die TimerJob-Administrationsseite wieder öffnen.

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

Löschen einer SharePoint-ServiceApplication mit PowerShell oder STSADM

Wer jemals in die Verlegenheit kommen sollte, eine SharePoint ServiceApplication zu löschen, sollte nicht uneingeschränkt das PowerShell-Cmdlet “Remove-SPServiceApplication” nutzen.

Es wird zwar gesagt, dass der Nutzer, der eine ServiceApplication anlegt, diese auch mittels PowerShell sauber löschen kann, allerdings hat meine Erfahrung bisher gezeigt, dass bspw. die Ausführung des Cmdlets mit dem Install-Account (bspw. SPSetup) immer in einer Endlosschleife endet.

Als Alternative zum PowerShell-Cmdlet beschreibt Donald Conlon in seinem Blog-Beitrag, die Nutzung von STSADM, das beim Löschen der ServiceApplication sogar erstaunlich schnell ist.

In meinem praktischen Fall hatte ich während der Migration einer SharedServiceProvider-Datenbank eine zusätzliche UserProfile-ServiceApplication erstellt, die ich wieder löschen wollte. Dazu musste ich folgende Schritte durchführen:

  1. Mittels PowerShell alle existierenden ServiceApplications ausgeben lassen (Get-SPServiceApplication),
  2. die ID der gesuchten ServiceApplication merken oder einlesen ($sa = Get-SPServiceApplication “<id>”)
  3. die gefundene ID als Parameter für das Löschen der ServiceApplication mittels STSADM nutzen (STSADM -o deleteconfigurationobject -id $sa.Id)
Mittels PowerShell kann man die ID der ServiceApplication einlesen, die dann als Parameter für das Löschen der ServiceApplication mittels STSADM -o deleteconfigurationobject benötigt wird.

Löschen einer SharePoint UserProfile-ServiceApplicaton mit PowerShell und STSADM

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

SharePoint 2010 – Referenzübersicht von CSS-Klassen

Seit SharePoint 2007 ist Heather Solomon als Design- und Layout-Experte bekannt. Nun hat sie ihre erfolgreiche Übersicht der wichtigsten CSS-Klassen für SharePoint 2007 auch für SharePoint 2010 zur Verfügung gestellt.

Die CSS-Klassen werden in unterschiedlichen Themengebiete unterteilt. Hier ist das Themengebiet "Suche" abgebildet.

CSS-Klassen-Referenz SharePoint 2007 - Thema: Suche (Quelle: www.heathersolomon.com)

Die CSS-Klassen (SharePoint 2010) werden in unterschiedlichen Themengebiete unterteilt. Hier ist das Themengebiet "Suche" abgebildet.

CSS-Klassen-Referenz SharePoint 2010 - Thema: Suche (Quelle: sharepointexperience.com)

Die Kenntnis der wichtigesten CSS-Klassen gehört meiner Meinung nach zum Grundlagenwissen eines jeden SharePoint-Designers. – Great job Heather! ;-)

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

Zugriff auf SharePoint-Datenbanken – Was erlaubt ist und was nicht

Da ich in meinen letzten Blog-Einträgen davon geschrieben habe, Lesezugriffe direkt auf einer SharePoint-Inhalts-Datenbank durchzuführen, will ich an dieser Stelle noch ein paar sensibilisierende Worte anbringen:

  • Prinzipiell ist der direkte Zugriff auf eine SharePoint-Datenbank (egal ob Inhalts-, Admin oder sonstige Datenbank) mit Vorsicht zu genießen und sollte nur von Experten durchgeführt werden!
  • Das Ändern eines SharePoint-Datenbank-Schemas führt dazu, dass sich das Produkt als Ganzes in einem nicht mehr von Microsoft “supporteten” Zustand befindet. (Falls solche Änderungen vorgenommen werden, sollte man immer in der Lage sein, ein Backup wieder herzustellen.)

“Direct modification of the SharePoint database or its data is not recommended because it puts the environment in an unsupported state.” (Quelle: http://msdn.microsoft.com/en-us/library/bb861829(v=office.12).aspx, 29.07.2011 > Die Quelle sollte auch als Grundlage für SharePoint 2010 angesehen werden.)

  • Microsoft hat für SharePoint 2007 ein paar Aktivitäten auf SQL-Server-Seite dokumentiert, die teilweise erlaubt sind. Ganz konkret ist allerdings nicht herauszulesen, was nun erlaubt ist und was verboten. (Unter anderem wird vom Anlegen von Triggern gesprochen, aber auch davon, dass vom direkten Lesen in SharePoint-Datenbanken abgeraten wird.

“… performing any read operations directly against these databases is unsupported.” (Quelle: http://support.microsoft.com/kb/841057/en-us, 29.07.2011)

Update: Es gibt auch ein WhitePaper für SharePoint 2010: Database maintenance for SharePoint Server 2010 (Stand: 12.05.2011)

Update: Seit 11.01.2012 auch in Deutsch verfügbar: Database maintenance for SharePoint Server 2010 (DE) (Stand: 23.01.2012)

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

SharePoint Migration – Duplicate ContentTypes, missing ContentTypes

Bei meinen bisherigen SharePoint-Migrationen bin ich immer wieder auf folgende zwei Probleme mit InhaltsTypen (ContentTypes) gestoßen.

  • ContentTypes waren doppelt vorhanden (duplicate ContentTypes) oder
  • ContentTypes waren gar nicht vorhanden (missing ContentTypes)

Duplicate ContentTypes sind zumeist eine Folge der Installation von Drittanbieter-Lösungen (WSPs). Hierzu zählt das Paradebeispiel “Fantastic Fourty” (wobei diese von Microsoft vorangetriebenen Website-Vorlagen nicht unbedingt in die Kategorie der Drittanbieter geschoben werden können ;-)).

Hinweis: Joel Oleson hat übrigens zeitgleich zu meinem Beitrag hier einen ausführlichen Beitrag zum Thema “Migration der Fantastic Fourty” geschrieben. (Quelle: http://www.sharepointjoel.com/Lists/Posts/Post.aspx?ID=469, 28.07.2011)

Um eine Migration erfolgreich durchzuführen, darf es keine ContentTypes geben, die die gleichen ContentType-IDs besitzen. Leider bemerkt man das Auftreten doppelter ContentType-IDs erst nach der Ausführung des PowerShell-Cmdlet “Mount-SPContentDatabase” (und nicht, wie man vermuten würde, beim zuvor ausgeführten “Test-SPContentDatabase” – den exakten Wortlaut der Fehlermeldung habe ich nicht mehr parrat, aber er müsste in etwa “A duplicate content type name ‘Resource’ was found.” heißen).

Das Vorkommen von duplicate ContentTypes kann man bspw. über SQL-Abfragen in Inhalts-Datenbanken der Quell-Umgebung (SharePoint 2007) realisieren. Für das Paradebeispiel der Fantastic Fourty gilt es, die ContentTypes herauszufinden, die im Namen das Wort “Ressource” beinhalten.

Hinweis: Zugriffe auf SharePoint-Datenbanken sind mit Vorsicht zu genießen.

SELECT * FROM ContentTypes WHERE ResourceDir like ‘%Ressource%’

Das Ermitteln von duplicate ContentTypes kann mittels SQL erfolgen.

Duplicate ContentTypes (Ressource) der Fantastic Fourty

In obigem Screenshot ist zu sehen, dass in der Spalte “ResourceDir” folgende Einträge bereits auf der Quell-Umgebung vorhanden sind:

  • Ressourcenreservierung
  • Ressource
  • Ressourcentyp

In der Spalte “Scope” kann man außerdem die zugehörigen SiteCollection-URLs einsehen.

Zum Entfernen der ContentTypes sollte man am besten das Feature deaktivieren, welches die ContentTypes angelegt hat. Im Falle der Fantastic Fourty wäre dies das Feature “Felder und Inhaltstypen für die Windows SharePoint Services-Anwendungsvorlagen” (Feature-Name “TSATypes”).

Das Feature "Felder und Inhaltstypen für die Windows SharePoint Services-Anwendungsvorlagen" legt ContentTypes beim Aktivieren an und entfernt diese beim Deaktivieren.

Das Feature der Fantastic Fourty, das die ContentTypes anlegt

Vom Löschen der ContentTypes direkt in der Inhalts-Datenbank rate ich aus zwei Gründen ab.

  1. Das manuelle Eingreifen in die Datenbanken des SharePoint wird von Microsoft nicht supported (führt zum Erlöschen jeglicher Support-Ansprüche).
  2. Ist man nicht selbst Ersteller eines ContentTypes, ist ungewiss, ob nicht noch weitere “Aufräumarbeiten” mit dem Löschen von ContentTypes einhergehen. > Lieber den Hersteller kontaktieren.

Missing ContentTypes sind Inhaltstypen, die vorhanden sein sollten, aber (aus welchen magischen Gründen auch immer) nicht vorhanden sind.

Während einer Migration (nach Ausführung des PowerShell-Cmdlets “Mount-SPContentDatabase”) erhält man bspw. den folgenden Fehler:

Feature upgrade incomplete for Feature ‘CTypes’ (Id: ’695b6570-a48b-4a8e-8ea5-26ea7fc1d162′) in Site ‘http://myportal/mywebsite/’. Exception: Der Inhaltstyp wurde nicht gefunden (ID: ’0×010107′)

Hierbei muss man wissen, dass die oben genannte ID die Feature-ID ist, von dessen Feature die ContentTypes erstellt werden sollen. Die ContentType-ID wäre in diesem Fall die zuletzt genannte ID.

  • SiteCollection-URL: http://myportal/mywebsite/
  • Feature-ID: 695b6570-a48b-4a8e-8ea5-26ea7fc1d162
  • ContentType-ID: 0×010107

Beim Aufruf der ContentType-Verwaltungsseite (http://myportal/mywebsite/layouts/ManageContentType.aspx?ctype=0×010107) erhält man folgende Fehlermeldung.

Der Aufrund der Content-Type-Verwaltungsseite zeigt für nicht vorhandene Content-Types eine Fehlermeldung.

Fehlermeldung beim Aufruf eines nicht vorhanden Inhalts-Typs (missing ContentType)

Das SharePoint-ULS-Log gibt auch ein paar Hinweise, die allerdings völlig irreführend sind.

Looking up typical site http://myportal/mywebsite/layouts/ManageContentType.aspx?ctype=0×010107 in web application myWebApplication

Failed to look up string with key “WorkflowTaskIP_Description”, keyfile

Localized resource for token ‘WorkflowTaskIP_Description’ could not be found for file with path: “(unavailable)”.

Die Lösung dieses Problems liegt darin, dass oben genannte Feature einfach zu aktivieren. Da es sich hierbei um ein verstecktes (hidden) Feature handelt, muss es via STSADM aktiviert werden.

stsadm -o activatefeature -id 695b6570-a48b-4a8e-8ea5-26ea7fc1d162 -url
http://myportal/mywebsite -force

Nach der Aktivierung bringt auch der Aufruf der ContentType-Verwaltungsseite keinen Fehler mehr und die Migration kann fortgeführt werden.

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

SharePoint Migration – Mit SQL herausfinden, wo sich WebParts befinden

Manchmal ist es interessant zu wissen, wo WebParts benutzt werden. Dies wird insbesondere bei Migrationen (bspw. von SharePoint 2007 auf SharePoint 2010) wichtig, wenn es sich um WebParts handelt, die u.U.

  • nur zu Testzwecken auf der Quell-Umgebung (2007) installiert wurden und auf der Ziel-Umgebung nicht mehr benötigt werden oder
  • für die Ziel-Umgebung (2010) überhaupt nicht supported werden (weil es bspw. eine SharePoint 2007 spezifische Entwicklung war)

Es gibt zwei Arten von WebPart-Problemen bei einer Migration:

  1. Defekte WebParts
  2. Fehlende WebParts (DLLs, Features, WebPart-Dateien)

Ein defektes WebPart wird vor der eigentlichen Migration auf der Quell-Umgebung mittels der STSADM-Operation “PreUpgradeCheck” ermittelt. Fehlende WebParts werden während der Migration auf der Ziel-Umgebung beim Ausführen des PowerShell-Cmdlets “Test-SPContentDatabase” ermittelt. (Eigentlich ist das Ermitteln fehlender WebParts auf der Ziel-Umgebung nur als zusätzliches Sicherheitsnetz in der Migrations-Manege zu betrachten, da bereits während der Analyse-Phase dokumentiert werden sollte, welche WebParts auf der Ziel-Umgebung installiert und deployt werden müssen.)

Korrupte WebParts werden mittels der STSADM-Operation PreUpgradeCheckd detailliert aufgelistet. Was fehlt ist die URL, wo dies korrupten WebParts genutzt werden.

STSADM-Operation PreUpgradeCheck zeigt korrupte WebParts an

Während der Migration werden die fehlenden WebParts angezeigt.

PowerShell-Cmdlet Test-SPContentDatabase zeigt fehlende WebParts

In beiden Fällen ist die einzig verwertbare Information die angegebene WebPart-ID. Um zu evaluieren, ob das genannte WebPart genutzt bzw. benötigt wird, müssen alle SharePoint-Seiten (also die URLs) ermittelt werden, die das WebPart nutzen.

Hierbei hilft STSADM nur begrenzt, da es nur die Website-URL ausgibt (STSADM -o EnumAllWebs -IncludeWebParts). Sobald sich ein WebPart aber bspw. in einer WebPart-Page befindet, müsste man beginnen in den Untiefen einer Website das gesuchte WebPart zu finden.

Was hilfreich ist, sind SQL-Abfragen. Ich habe mal (inspiriert durch einen MSDN-Foren-Eintrag) drei sehr triviale SQL-Queries zusammengetragen, die das Auffinden von WebParts anhand einer WebPart-ID erleichtern.

  1. SELECT tp_SiteId, tp_PageUrlID FROM [WebParts] where tp_WebPartTypeId = ‘<WebPart-ID>
  2. SELECT PortalURL FROM [Sites] where Id = ‘<tp_SiteId>
  3. SELECT DirName, LeafName FROM [AllDocs] where Id = ‘<tp_PageUrlID>

Hinweis: Zugriffe auf SharePoint-Datenbanken sind mit Vorsicht zu genießen.

Die URL einer SharePoint-Page, die das gesuchte WebPart beinhaltet setzt sich dann wie folgt zusammen: <PortalURL>/<DirName>/<LeafName>

Das Löschen von WebParts ist übrigens über die WebPart-Verwaltungsseite möglich. Dazu einfach an die gefundene URL den HTTP-Get-Parameter “contents=1″ anhängen, dann wird man auf diese Seite weitergeleitet. Also bspw. <URL>?contents=1

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

SharePoint Health Analyzer – Product / patch installation or server upgrade required.

Nach der Installation der aktuellen SharePoint-Updates (SP1 + Language-Packs DE für SP1 + das Re-Release vom CU Juni 2011) erhielt ich heute auf einer SharePoint-Farm folgende Health-Analyzer Fehlermeldung:

Die Fehlermeldung im Health-Analyzer besagt, dass der Patch-Stand innerhalb der SharePoint-Server einer SharePoint-Farm nicht übereinstimmen.

Fehlermeldung im Health-Analyzer: Product patch installation or server upgrade required

Die Übersicht der Server innerhalb der SharePoint-Farm gibt mir weitere Hinweise.

Es fehlen mehrere Patches bzw. Updates, die angeblich nicht installiert sind (sie sind es aber).

Die Übersicht aller Server in der SharePoint-Farm: Auf dem WFE-Server fehlen Patches/Updates.

Die Meldung “Product / patch installation or server upgrade required.” besagt, dass mir beim Update-Prozedere wohl ein Fehler unterlaufen ist und deshalb eine ganze Reihe von Updates noch nicht auf allen SharePoint-Servern in identischer Weise zur Verfügung stehen.

Zur Information, wie mein Update-Prozedere grob aussah: Ich hatte

  1. auf jedem SharePoint-Server alle oben genannten Updates installiert, dann
  2. PSConfig.exe auf dem App-Server (CA) laufen lassen und zuletzt
  3. PSConfig.exe auf den WFE-Servern laufen lassen.

PSConfig habe ich dabei wie folgt über die Kommandozeile aufgerufen.

PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures

Leider war ich mir sicher, dass mir kein Fehler beim Update-Prozedere unterlaufen ist. Also zog ich das Log vom PSConfig zu Rate. Dieses gab mir folgende ausführliche Fehlermeldung.

An PostSetupConfigurationTaskException was thrown on The applicationcontent command is invalid or a failure has been encountered.
The server farm will not work with missing installs. Add “-cmd installcheck -noinstallcheck” to the command-line to ignore this warning.

The following is missing on MyServer-WFE:

Hotfix for Microsoft SharePoint Foundation 2010 (KB2536601)
Microsoft SharePoint Foundation 2010 Service Pack 1 (SP1)

Microsoft SharePoint Foundation 2010 Language Pack Service Pack 1 (SP1)

Hotfix for Microsoft Office Server (KB2536599)
Microsoft SharePoint 2010 Service Pack 1 (SP1)

…<und viele solcher Einträge mehr>…

Microsoft SharePoint 2010 Service Pack 1 (SP1)

.  The task driver will now quit.

Am interessantesten war für mich, dass ich mein PSConfig-Kommando einfach um einen Parameter erweitern sollte. Das PSConfig-Kommando sieht also wie folgt aus:

PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures -cmd installcheck -noinstallcheck

Nach der Ausführung dieses Kommandos auf allen SharePoint-Servern war der Health-Analyzer Fehler behoben. (Ein tolles Gefühl für Freitag nach Eins.)

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

Basic SharePoint-Google-Maps-WebPart for SharePoint-Lists auf Codeplex

Heute habe ich mein erstes Codeplex-Projekt erstellt. Das Projekt hat den anspruchsvollen Namen “Basic SharePoint-Google-Maps-WebPart for SharePoint-Lists” und ich werde nun den Sinn, die Motivation und dessen Mehrwert näher erläutern.

Der Sinn – Warum Codeplex?

Obwohl ich die Entwicklungsarbeiten weitestgehend abgeschlossen hatte, habe ich die Sourcen auf Codeplex hinterlegt, da ich schon immer ein eigenen Codeplex-Projekt erstellen wollte. ;-) Die Vorteile von Codeplex einer professionellen Versionsverwaltung (Microsoft-TFS) werden zwar erst dann an´s Licht gelangen, wenn sich dem Projekt mindestens ein zweiter Codeplex-Nutzer anschließt – aber irgendwie könnte ich mir vorstellen, dass es die Kombination SharePoint & JavaScript-Liebhaber nicht sehr häufig gibt. Von daher ließe sich über die Sinnhaftigkeit zur Nutzung von Codeplex streiten. Aber ich bin da optimistisch…

Die Motivation – Gibts da nicht schon dutzende SharePoint-Google-Maps-WebParts?

Eben nicht! Aber meine Motivation war eigentlich eine andere.

Ich wollte die Standorte aller Kontakte, die in einer SharePoint-Kontakt-Liste enthalten waren, auf einer Landkarte anzeigen. Bis hierher würden bekannte Lösungen (bspw. GoogleMapsWebPart) meine Anforderungen erfüllen. Dummerweise bin ich aber Besitzer eines WSS3.0-Hosting-Paketes auf dem ich keine SharePoint-Solutions (WSPs) installieren darf. Außerdem schwebte mir vor, dass ich auch gern nur bestimmte Kontakte (bspw. alle Kontakte aus dem Bundesland Sachsen) auf der Landkarte sehen wollte. Die mir bekannten Lösungen können aber immer nur eine bestimmte Sichtweise (View) einer SharePoint-Liste darstellen. Und ehrlich gesagt wäre es mir zu öde, für jeden View ein extra WebPart zu konfigurieren. – Die mir bekannten Lösungen erfüllten also meine Anforderungen nicht.

Als SharePoint & JavaScript-Fan habe ich mich gefragt, ob es prinzipiell möglich ist, eine Landkarte, deren Inhalte (also die Marker) aus einer SharePoint-Liste stammen, nur mit JavaScript darzustellen. Kombiniert mit den Möglichkeiten eines Listen-WebParts (bspw. das Filtern und Sortieren) ergeben sich unendlich viele Möglichkeiten. Damit war mein Entwicklungsdrang geweckt…

Der Mehrwert – Was genau ist denn jetzt so toll am neuen Google-Maps-WebPart für SharePoint-Listen?

Die neue Lösung ist eigentlich nur ein bisschen Html und JavaScript. Auf einer SharePoint-Seite, die das Listen-WebPart enthält, muss ein Inhalts-Editor-WebPart (was ein Standard-SharePoint-WebPart ist) mit dem genannten bisschen Html+JavaScript eingefügt werden.

Ist alles korrekt konfiguriert, wird in der Menü-Toolbar des Listen-WebParts ein zusätzlicher Menü-Punkt “Google-Maps” angezeigt. Durch Klicken auf diesen neuen Menü-Punkt wird unter der SharePoint-Liste die Landkarte dargestellt. Auf der Landkarte werden alle aktuell sichtbaren Listen-Elemente als Marker dargestellt. Durch das Filtern der SharePoint-Liste ändern sich also auch die Marker auf der Landkarte.

Die Vorteile lassen sich schnell aufzählen.

  • Kein Installieren von SharePoint-Solutions / Sandboxed-Solutions (WSPs) notwendig.
  • Es können SharePoint-Listen als Quelle genutzt werden. Es muss nur sichergestellt werden, dass die Informationen der Koordinaten (Längen- und Breitengrad / Latitude und Longitude) bzw. die Adress-Infos (Pflichtangabe: Stadt; Optional: Straße, PLZ, Land) in der Liste zu finden sind.
  • Die Standard-Funktionalität einer SharePoint-Liste wird um eine Landkarten-Funktion erweitert.
  • Durch die Sortier- und Filterfunktionen einer SharePoint-Liste sind beliebig viele Sichten der Landkarte möglich. Oder anders: Es muss nicht für jede Sicht ein extra WebPart hinzugefügt und konfiguriert werden.
  • Traffic-Arm durch Nachladen der Landkarten-Infos mittels Ajax (JQuery + owssrv.dll + Google-Maps-API-v3).
  • Unterstützt SharePoint 2007 und SharePoint 2010.
  • Durch Nutzung von Google Maps Api v3 ist kein Google Maps Key notwendig (vgl. Punkt 5.2 der Google Maps Api Terms).

Natürlich gibt es auch einige Nachteile. (Dafür sind dann die anderen Google-Maps-WebParts da… ;-))

  • Die Anzeige eines Listen-WebParts ist notwendig. (In dessen Menü-Toolbar wird ja der Google-Maps-Link dargestellt.)
  • Es wird in der aktuellen Version (v1.1) nur ein Listen-WebPart je SharePoint-Seite unterstützt. (Gibt es mehr, wird der Google-Maps-Link nicht in der Menü-Toolbar gezeigt.)
  • Konfiguration erfolgt direkt im JavaScript-Quellcode. (Ein bequemes Konfigurieren über die WebPart-Toolpane würde einer installationsfreien Lösung widersprechen.)

Mein Fazit – Hoffnungen

Ich hoffe, ich kann noch ein paar SharePoint-Enthusiasten (die sogenannten Information-Worker und Power-User) für diese Art der Landkarten-Darstellung für SharePoint-Listen begeistern. Mir hilft sie schon jetzt ungemein. – Und besonders gespannt bin ich, wie viele Codeplex-Nutzer sich meinem ersten Codeplex-Projekt anschließen werden. (Ich bin mal mutig und spendiere einen Kasten Bier in der nächsten Dresdner Doppelkopfrunde für jeden Supporter meines Codeplex-Projektes. Bei 10 sollte dann aber langsam Schluss sein.. ;-))

Veröffentlicht unter JavaScript, Microsoft, SharePoint 2007, SharePoint 2010, Web | Verschlagwortet mit , , , , , , | 10 Kommentare