SharePoint : Marco Scheel aka GeekDotNet

Heute habe ich eine Mail mit der Info des aktuellen CU für einen der offenen SharePoint PSS Cases bei einem Kunden bekommen. Es wurde auf das Release des aktuellsten Updates für SharePoint hingewiesen. Es gibt noch kein “Rundum-Sorglos” Paket, aber für den dringenden Fall kann man wie in dem Blogpost genannt vorgehen und “traditionell” installieren.

Joerg Sinemu - February Cumulative Update for WSS V3 and MOSS 2007

Wir hatten vor einigen Monaten ein Case zum Thema BLOB Caching eingestellt. Es ging darum für ein Intranet Videos (Flash – FLV) zu cachen, damit die Datenbank entlastet wird. An sich funktionierte das auch super, allerdings wurde auf allen System des Kunden ab einer Größe von 40-50 MB die Datei nicht ausgeliefert und man bekam eine Anmeldemaske (HTTP Error 401). Es konnte sich aber nicht authentifiziert werden. Nach einigen Repros auch bei MS dann die Info, dass es eine API des IIS Schuld daran war. Kurzerhand hat man die gerufene API gewechselt und nun soll es wieder gehen… bin mal gespannt :-)

Hier der von mir genannte Entry im KB Artikel:

If blob caching is enabled for a Web site, you cannot download files whose size is more than 32 megabytes (MB) from that Web site.

Ciao Marco

Nach der letzten Installation IU und CU August 2008 hatte ich einen kurzen Schocker, da die Suche nicht mehr wollte. Wir setzen die “Facetted Search” in Version 2.0 ein, um die Suche aufzuwerten. Ich wurde allerdings mit folgenden Fehlern in den Webparts beglückt:

The type initializer for 'Microsoft.Office.Server.EvaluatorModeProvisioning.OfficeServerProductToProvision' threw an exception.

Eine kurze Google-Recherche hat mich auf die simple Lösung durch IISRESET gebracht :-) Wow. War das einfach. Bei der Installation und der anschließenden Deinstallation der Facetted Search 2.5 kam der Fehler allerdings wieder und die Lösung brachte diesmal nicht IISRESET, sondern der Trust Level in der Web.Config der betroffenen WebApplication.

Ciao Marco

Lektion gelernt! Ich habe bei einem Kunden gestern der “Infrastructure Update” (IU) und die “Cumulative Updates August 2008” (CU) installiert. Auf der Startseite des Unternehmensintranet werden Nachrichten aus allen Bereichen abgebildet. Zur optischen Auffrischung und zur Kategorisierung wird ein Bild für das zugehörige Unternehmen (Unternehmens- oder Markenlogo) abgebildet. Der verwendete ContentType hat ein Feld “Unternehmen” vom Typ “Lookup”. uIm Content Query WebPart (CQWP) lese ich dann die ID des Lookup aus und nutze diese, um auf ein Bild als Source zu verweisen. Für solche Aktionen muss ja wie bei Heather Solomon beschrieben der WebPart mit den entsprechenden CommonViewFields “bestückt” werde.

Nach der Installation der IU und CU habe ich die Startseite geprüft und festgestellt, das die Bilder nicht mehr funktionieren. Hier mein Eintrag aus dem Webpart:

   1: <property name="CommonViewFields" type="string">Unternehmen,Lookup;</property> 

In der ItemStyle.xsl greife ich dann für die Source über folgenden Variablendefinition zu:

   1: <xsl:variable name="UnternehmenId"> 

   2:   <xsl:value-of select="@Unternehmen" /> 

   3: </xsl:variable> 

Ergebnis vor der Installation war die ID des Lookupvalues. Ich musste etwas googlen und habe dann folgendes Versucht. Ich habe in den CommonViewField einfach den Typ weggelassen:

   1: <property name="CommonViewFields" type="string">Unternehmen;</property>

Als Ergebnis habe ich dann ID und Inhalt des Feldes bekommen (Format bei SharePoint ist: ID;#TITELCOLUMNVALUE). Ich habe mein XSL also umgebaut und siehe da es funktioniert. Hier der Code:

   1: <xsl:variable name="UnternehmenId"> 

   2:   <xsl:value-of select="substring-before(@Unternehmen, ';')" /> 

   3: </xsl:variable>

Wenn man drüber nachdenkt ist das total logisch :-) Mit Typ in den CommonViewFields löst er mir den Inhalt gleich darstellungsfertig auf. Ohne den Typ bekomme ich das was wirklich gespeichert wurde.

Ciao Marco

Meine Einschätzung hat sich bestätigt: Der Namics SharePoint Blog hat jetzt wohl Feedback von Microsoft zum Thema "SQL 2008 BLOB Support" in SharePoint bekommen. Den vollen Artikel findet iher hier.

Es wird allerdings Hoffnung gemacht, das daran gearbeitet wird. Ich für meinen Teil würde lieber andere Features in den neuen Versionen sehen, als so eine Funktion. Ich würde mich auch einfach über noch mehr und schnellere Bugfixes freuen. Zum Beispiel: Der AAM Bug des "Infrastructure Updates" scheint zumindest behoben, wenn er auch nocht nicht offiziell zum Download steht. Über einen PSS Call zu einem anderen Thema kam der mit rein, sobald ich das gestetet habe gibt es Feedback und bestimmt den offiziellen Download :-)

Ciao Marco

In meinem RSS Reader bin ich über einen Post von Namic gestolpert:
http://sharepoint.namics.com/2008/08/moss_2007_auf_sql_2008_install.html
Es werden Spekulationen geäußert, dass man mit Hilfe des SQL2K8 die BLOB's also die Dateien in SharePoint auf die Platte auslagern könnte. Ich selber kann mit kein Out-Of-The-Box Funktionalität vorstellen. Es ist sicher wünschenswert, aber da es kein Transparentes Feature für die anwendenede Software (in diesem Fall SharePoint) ist, wären hierfür Codechanges notwendig. Microsoft bietet ja bereits eine Möglichkeit über die External BLOB Storage Funktion. Größtes Problem aus meiner Sichta: Es gibt keine Migration von einem Szenario (BLOB in DB und BLOB on DIsk) ins andere. Mehr Infos auch hier im Blog von Todd Carter. Es wäre schön, wenn MS es tatsächlich implementieren würde. Namics hat bereits einen Request an MS gestellt und ich bin sehr gespannt was das Ergebnis sein wird :-)

Was aber SQL 2008 für SharePoint schon heute bringt hat Joel Oleson zusammengefasst:
http://blogs.msdn.com/joelo/archive/2008/03/10/top-10-sql-2008-features-answer-why-plan-to-upgrade.aspx

Ich habe meine ersten Erfahrungen während der Beta Phase gemacht. Es ist ein tolles Produkt, allerdings ändert sich erstmal für SharePoint in den meisten Installationen wenig (es sei denn die Performance ist bei gleicher Hardware wirklich besser). Interssant wird meiner Meinung nach, die Integration der Reporting Services mit den neuen Charts. Hat schon jemand gewechselt und kann für SharePoint da ne Aussage treffen?

Achso: Nicht falsch verstehen... ich finde SQL 2008 richtig gut und er ist für mich in jeder neuen SharePoint Installation gesetzt, solange der Kunde dieses Szenario supporten kann.

Ciao Marco

Eben in dem Blog von Benjamin Wegner gefunden:

Onlineblog - Sharepoint und Riesentorte

Leider alles nicht so witzig, wie es sich anhört. Die Installation alleine hilft nicht, die Webparts müssen entsprechend angepaßt werden. Was nicht richtig durch kommt, die Personensuche ist ebenfalls betroffen. Namen wie "Mustermann" würden ebenfalls nicht als Treffer auftauchen.

Ich hab einen der größeren Kunden betreut, der noch immer von dem Problem betroffen ist. Den Hotfix, den wir damals getestet haben (der hier nun öffentlich ist), hat zwar das Problem gelöst, an sich handelt es sich aber lediglich um einen Workaround. Die Lösung wäre, den Wordbreakter entsprechend zu korrigieren.

In den eigenen API Calls im C# Code muss genau auf so etwas geachtet werden, da es wirklich nur ein Workaround ist der an der Oberfäche greift.

Von uns kamen übrigens die letzten beiden Wörter... für mich sind es die "Unwörter für 2007 und 2008" geworden :-S

MS KB Artikel 950439:
No results are returned when you search for German compound words or for German compound names in SharePoint Server 2007

Ciao Marco

Ich habe eben versucht, auf dem Microsoft Demo Virtual PC (WSSv3 + SP1) eine SiteDefinition zu deployen. Es gab leider nur folgende Fehlermeldung:

   1: Error    1    Unable to generate a temporary class (result=1).

   2: error CS0016: Could not write to output file 'c:\Documents and Settings\Administrator\Local Settings\Temp\xyqxz-fg.dll' -- 'Could not execute CVTRES.EXE.'

   3:         0    0    

Kurze Suche in Google brachte folgendes:
http://forums.msdn.microsoft.com/en-US/msbuild/thread/b93ea3ff-8aa1-4893-a6bf-c4c064633528/

Die folgenden Commands haben dann tatsächlich die LKösung gebracht:
devenv -resetsettings
devenv -resetskippkgs
devenv -safemode

Ciao Marco

In einer der Kundenumgebungen läuft neben der SharePoint Farm auch ein Microsoft Office Project Server 2007 (MOPS). Wir hatten in der Vergangenheit schon Proleme mit dem Einrichten der OLAP Cubes. Es führte bis zu einem MS Support Case, der anschließend dafür sorgte, dass die MSDN Dokumentation entsprechend aktualisiert wurde. Leider ist es nicht der letzte Fehler in diesem Umfeld. Ich habe jetzt eine Anfrage bekommen, weil die Datenanalyse nicht funktioniert. Das ActiveX Control hinter dem Navigationspunkt ist ein Office Web Components (OWC) Element. Dieses Element baut im Hintergrund eine OLEDB Verbindung zum Microsoft SQL 2005 - Analaysis Sever (SSAS) auf. Der Kunde hatte nun das klassisch IT Probelm. Auf einem Rechner geht es noch und auf einem anderen Rechner funktioniert es nicht mehr. Es hat natürlich irgendwann mal auf allen Clients funktioniert und es wurde natürlich nichts verändert. Eine kurze Google Suche zur Fehlermeldung "Cannot connect to the server <SERVERNAME>. The server is either not startet or too busy." brachte mich auf die Spur der OLEDB Client Version für SSAS. Es wurde schnell klar, dass die Fehlermeldung nicht unklarer sein könnte. Ich konnte mich auf zwei Citrix Server aufschalten, die jeweils einmal funktioniert und einmal nicht funktioniert. Offensichtlicher Unterschied: Die Version des "Microsoft OLEDB Provider for Analysis Services X.0".

Der Server mit der fehlerhaften Meldung hatte nur den OLEDB Treiber für Version 8.0 ( = Microsoft SQL Server 2000):
 

Der Server mit der erfolgreichen Meldung hatte den OLEDB Treiber für Version 9.0 ( = Microsoft SQL Server 2005): 
 

Die Installation des Treiber aus dem Microsoft SQL 2005 Feature Pack Feb 2007 (für SP2) hat die nötige Lösung gebracht.
http://www.microsoft.com/downloads/details.aspx?FamilyID=50b97994-8453-4998-8226-fa42ec403d17&displaylang=en

Ciao Marco

In meinem Vorgängerpost habe ich ja kurz beschrieben, was für Hürden das Add-In des Report Servers (MS SQL 2008) aufstellt und wie man drüber kommt. Grundsätzlich bleibt anzumerken, dass der Microsoft SQL Server 2008 ohne echten IIS auskommt. Seit 2005 konnte er so schon WebServices direkt ohne WebServer anbieten. Allerdings wurde für die Reporting Services (SSRS) in der Version 2005 noch ein echter IIS benötigt. Mit dem aktuellen SQL 2008 CTP Feb ist dies nicht mehr nötig. Der SSRS läuft komplett im SQL über HTTP.SYS.

Dieser Post widmet sich kurz der Installation der Serverseite des SSRS. Es gibt nämlich ein paar Änderungen... sehr grundsätzliche Änderungen:

"To join a report server to a SharePoint farm, the report server must be installed on a computer that has an instance of a SharePoint product or technology. You can install the report server before or after installing the SharePoint product or technology instance."
BOL: Requirements for Running Reporting Services in SharePoint Integrated Mode
http://msdn.microsoft.com/en-us/library/bb283190(SQL.100).aspx

Verstanden? Genau der Server, der den Report Server (WebService) anbietet, muss in die Sharepoint Farm! Hinweise dazu gibt es auch hier:
Planning a Deployment Mode (Reporting Services)
Deployment Topologies for Reporting Services in SharePoint Integrated Mode

Vorteile sind eine bessere und tiefere Integration (z.B. bessere Webparts), aber was sind weitere Folge?

1. Auf dem SQL Server muss eine Sharepoint Server installiert werden
   1. Extra Server der gepatched werden muss (HotFixes, Rollups, ...)
   2. Extra Lizenzkosten für einen SharePoint Server (nicht so schlimm)
   3. IIS-Komponenten (nicht nur HTTP.sys) auf dem SQL
2. oder auf einem SharePoint Server der Farm (z.b. Maschine mit der Rolle: Indexer, ExcelServices, ...)
   1. Wartung ist nicht so aufwendig wie anders herum (siehe 1.) aber muss gemacht werden
   2. Extra Lizenzkosten und diese können extrem hoch werden, da in der Regel nach CPU lizensiert wird. Je nach Edition kommen hier schnell hohe 5 stellige Euro-Beträge zustande.

Ich habe mich entschieden für meine Testumgebung, die Installation auf dem SQL Server zu machen. Ich habe alle Services "disabled" und so kaum einen "Overhead". Allerdings muss ich den IIS auf dem Server installieren, weil das MOSS erzwingt.

Ohne SharePoint kommt zu Beispiel:

Nächster Fehler:
"Report Server may not have joined the SharePoint farm, or Report Server service account may not have been granted access to farm."
Eine Lösung habe ich noch nicht. Nur ein Workaround. Ich versuche, die ganze Umgebung mit Kerberos als Authentifizierung zu fahren. Im Windows Server 2008 hat sich hier ein wenig das Modell hinter dem Process Model geändert. Im Moment nur soviel: "KernelMode Authentication". Ich lasse nun den ReportServer also nicht unter einem Domain Account laufen, sondern unter LocalSystem. Anders war es leider nicht zu realisieren. Im Moment ist die Umgebung mit W2K8 und SQL2K8 und dann noch SharePoint mehr als "unbekannt"... und das geht nicht nur mir so... Microsoft arbeitet ja auch noch am neusten SQL Server also ist im Moment noch sehr unklar, wo genau der Fehler liegt. Sharepoint an sich funktioniert ja sehr gut, auch mit Kerberos.

Bei weiteren Problemen mit der Authentifizierung sollte man mal in die Microsoft Books Online (BOL) für den SQL 2008 rein schauen.
Thema: Trouble Shot Authentication Report Server use Build in Account with Service type HOST

Fazit
Noch ist die Installation nicht ganz rund. Der RC0 ist glaube ich vor kurzem raus gegangen. Ich weiß nicht, ob ich die Zeit finde vor dem RTM mich näher damit zu beschäftigen, aber ich denke wir sind auf dem besten Weg. Die Architekturänderungen für die Farm Integration findet ich etwas unglücklich, aber die Kundenakzeptanz wird zeigen, wie lange diese Lizenzauswirkungen bestand haben :-)

Ciao Marco

Version 0.1 - 2008-05-07
Version 0.2 - 2008-06-24
Version 0.3 - 2009-06-24 (SP2, CU, IIS7, SQL2K8)

Vorbedingungen:

• Betriebssystem und alles weitere Software ist in der Hauptsprache Englisch
• OS und Software ist 64-Bit
• Alle Server haben min. 4 GB RAM
• Der Datenbankserver hat 8 GB RAM und min. 2 CPU's mit 2 Cores
• Min. 2 Partitionen mit zwei getrennten Plattensystemen
• PowerShell auf allen Sharepoint Servern für Scripting

Über die Punkte oben kann man streiten, aber das Sizing ist für mich min. wenn ein Kunde ein Farm mit zwei SharePoint und einem DB Server aufbaut. Die Hardware ist so oder so 64-bit fähig und 8 GB RAM sind heute günstig zu erwerben. Der Erfolg einer SharePoint Anwendung steht und fällt mit der Performance des SQL Servers. Also sind das meine Wunschrahmenparameter. Beim SQL mache ich nur Zugeständnisse, was die Platten angeht. Für alle Datentypen (SystemDB's, tempdb, Datafiles und Logfiles) eigene getrennte Plattensystem zu haben, ist wünschenswert, aber das kann heute gerade bei großen Datenmengen teuer werden, besonders, da ich bisher auch nur wenige schnelle SAN Implementierungen gesehen habe :-)

1. Deaktivierung der Virenscanner für die Installation = Beschleunigung des Setup (besonders wichtig beim Ausführen von PSCONFIG)
2. IIS Default Site stoppen und IIS Logsettings (Pfad und Details) konfigurieren
3. Installation MS SQL Server 2005 SP2 MS SQL Server 2008 SP1
   1. Konfiguration der Default Datenbankpfade auf die entsprechenden Laufwerke
   2. Einstellung für ein sinnvolle Defaultgröße (min. 100 MB Daten und 50 MB Log)
   3. Wachstumsraten anpassen (min. 100 MB Daten und 50 MB Log)
   4. Die Größen richten Sich nach dem geschätzten Volumen, je mehr man ausgeben darf desto besser. Ich habe auch schon Konfigurationen mit 20 GB (ja GB) Initialgröße gemacht, so verhindert man die Fragmentation auf der Platte und erhöht die Wahrscheinlichkeit, die Anwendung schnell zu halten
4. Installation MOSS 2007 mit SP1
5. Installation Language Packs falls notwendig
   1. Install WSS Language Pack (e.g. x64, German)
   2. Install MOSS Language Pack (e.g. x64, German)
   3. Installation WSS/MOSS SP1 Language Packs
6. Installation Post SP1 Rollups (http://www.harbar.net/articles/postsp1.aspx)
   Installation SP2 (siehe auch mein SP2 Artikel)
1. WSS SP2 + WSS Language Pack SP2
2. MOSS SP2 + MOSS Language Pack SP2
7. Installation des letzten Cumulative Update (CU)
8. IIS Logverzichnis von Laufwerk C um konfigurieren auf ein anderes Laufwerk
9. (Optional) Für weitere Server in der Farm alle Schritte bis hier her wiederholen
10. DNS einrichten
    1. Portal: portal.domain.local
    2. MySite: my.domain.local
    3. SSP: moss-prod-ssp.domain.local
    4. Admin: moss-prod-admin.domain.local
11. Einrichten der Service Accounts
    1. Farm: svcMossProd
    2. SQL: svcMossProdSql
    3. Crawl: svcMossProdCrawl
    4. Content Access: svcMossProdContentAccess (Achtung: Innerhalb von SharePoint mur dann der Netbiosname verwendet werden, also die ersten 20 Zeichen = svcMossProdContentAc)
    5. SSP: svcMossProdSsp
    6. MySite + Portal: svcMossProdApp
12. Einrichten der Security Gruppen
    1. Farm Admins: sec-MossProdFarmAdmin
       Alle User die Sharepoint administrieren sollen
    2. Service Accounts: sec-MossProdSvcAccounts
       Alle Service Accounts svcMossProd*
13. Konfiguration der DCOM Config für alle AppPool und Service Accounts (sec-MossProdSvcAccounts) mit "Local Launch" und "Local Activation" für "IIS WAMREG admin service" und "OSearch" auf allen Servern (ohne SQL)
14. (Optional) Service Principal Names (SPN) und Delegation pflegen
    1. Entscheidung für oder gegen IIS7 Kernelmode Authentication (Wenn NLB für die WFE geplant ist, dann auf jeden Fall gegen Kernelmode AUth entscheiden)
    2. Setzen der SPN’s auf die Maschine(n) oder die Service Accounts (Kernelmode Auth = Off)
15. Erstellen einer Farm auf dem Applikationsserver (Crawl, Central Admin)
16. Joinen der Server (1 WebFrontEnd Server oder zwei bei Load Balancing bevorzugt Windows NLB)
17. Konfiguration der Rollen (WFE = WebApplication, Query / APP = CentralAmin, Index)
18. Konfiguration des Shared Service Provider
    1. Anlegen einer eigene Applikation für den SSP (moss-ssp.domain.local)
    2. Anlegen einer eigene Applikation für die MySite (my.domain.local)
    3. Alle Applikationen bekommen einen eigene extra Domain User als AppPool Account (falls wir Kerberos machen wollen)
    4. Alle Anwendungen werden mit HostHeader angelegt (unterstützt den Einsatz von Kerberos und vermeidet kryptische URL's mit Port am Ende)
19. Alle Datenbanken, die angelegt werden, bekommen eindeutige Namen. Ausnahmen sind ConfigDB (bleibt beim Standard) und ContentDB der Central Administration (weil -> keine Relation zu Aufwand und Nutzen). In der Regel Kennzeichnung des Systembetriebs im Namen (MOSS_PROD_Portal_00).
20. Konfiguration des Operations Tab. Wichtige Optionen:
    1. "Diagnostic logging": Pfad vom Standard auf C umbiegen auf ein anderes Laufwerk. Wichtig: Dieses Setting wird in der Farm genutzt und alle beteiligten Server die SharePoint Software installiert haben, müssen über das Laufwerk und den Ordner verfügen. Es kann sonst zu unverständlichen Fehlern wie "Access Denied" kommen.
    2. "Update farm administrator's group": Farm Administrators durch eine AD Gruppe für die MOSS Administration erweitern. Diese Gruppe verwenden wir auch weiter, da der Setup Account sonst der einzige ist der alle Rechte hat und die Pflege so sehr umständlich wird.
21. Konfiguration des Application Management Tabs. Wichtige Optionen:
    1. "Create or extend Web application": Erstellen er Anwendung für die Portal Applikation. Auch hier HostHeader für die URL, eigener AppPool Account (Alternative: Pool der MySite mitbenutzen), Pfad auf anderes Verzeichnis als C setzen, DB Namen vergeben.
    2. "Web application general settings": Einstellen der default Zeitzone für MySite und Portal
    3. "Content databases": Bei Anwendungen mit hohen userzahlen und vielen SiteCollection (MySite -> User = SiteCollection) erzeuge ich eine sinnvolle Anzahl an Datenbanken. Beim Anlegen von SiteCollections kannverteilt sich so die Datenmenge auf x Datenbanken was für Backup- und Restore Operatione gut ist. Es kann auch sinnvoll sein, dass wir die Portal CMS SiteCollection in eine eigene Content DB legen, diese dann offline nehmen, damit wir in der Datenbank nur eine SiteCollection haben. Der Rest an SiteCollections verteilt sich dann entsprechend.
    4. "Self-service site management": Für MySite einschalten
    5. "Policy for Web application": An dieser Stelle mache ich es so, dass ich auf alle Applications die Farm Administrator Group (sec-MossProdFarmAdmins) aus de AD mit Full Control berechtige. Es sollten sowieso nur hoch previligierte Accounts enthalten sein.
22. Konfiguration des Shared Service Provider. Wichtige Punkte:
    1. "Site Settings - Advanced permissions": Farm Admin AD Gruppe mit Full Control berechtigen (ist zwar per Policy auch schon drin, aber der Vollständigkeit halber sollte das pasieren)
    2. "Personalization services permissions": Farm Admin AD Gruppe auf alle Optionen berechtigen (ist bisher nicht durch Policy abgedeckt)
    3. "User profiles and properties": Import und Schedule konfigurieren
    4. "Search settings": Schedule konfigurieren
23. SQL Datenbanksettings
    1. Check der MOSS Datenbanken auf: Initialgrösse, Wachstumsraten, Recovery Model (Simple oder Full)
    2. Backup der Datenbanken. Wichtig: Bei Recovery Full müssen die Logs gebackuped werden, sonst läuft die Platte voll
    3. Wartungsplan: Index Rebuild/Reorg nach MS Whitepapaer und Anforderungen
24. Backupscripte für IIS Metabase Schedulen
25. 12 Hive - BIN in den Enviroment Variables in den Pfad aufnehmen
26. STSADM PowerShell Kombi für Speichern der Ergebnisse von STSADM - o enumsites -URL <portal + mysite url> für Restore und Reportingzwecke
27. Screenshots nicht vergessen :-) Zur Orientierung: Bei mir wird es in der Regel ein Dokument mit ca. 150 Screenshots
28. (Optional) Bierchen trinken, Frau anrufen, dass es später geworden ist und tief Luft holen

Ciao Marco