If you want to show all Application Templates for WSS 3.0 (aka Fab40) to a customer it can be very time consuming to deploy all the templates manually and create all the websites by hand.

Solution: Script it!

1. Download the application templates for WSS 3.0:
   http://www.microsoft.com/downloads/en/details.aspx?FamilyID=5807b5ef-57a1-47cb-8666-78c1363f127d&displaylang=en
2. Deploy the templates, first deploy the Application Template Core WSP

   stsadm -o addsolution -filename ApplicationTemplateCore.wsp
   stsadm -o deploysolution -name ApplicationTemplateCore.wsp -allowgacdeployment –immediate

   stsadm -o execadmsvcjobs

   stsadm -o copyappbincontent

   If you encounter an error with this do the deploy again with parameter –force

   stsadm -o deploysolution -name ApplicationTemplateCore.wsp -allowgacdeployment -immediate -force

   Or use this script:

   Just rename the txt file to *.bat and change the paths for your environment.

    

3. After this, create the Websites (webs) with the templates. You need the ID of the site templates. You can find out with this powershell script:
   
   

   [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") 
   $theSiteColl = New-Object Microsoft.SharePoint.SPSite("http://yourserver") 
   $theWeb = $theSiteColl.OpenWeb() 
   $theWeb.GetAvailableWebTemplates(1033) | select name, title 

4. Create the sites with stsadm:

stsadm -o createweb -url http://yourserver/CallCenter -lcid 1033 -title CallCenter -sitetemplate callcenter#0

Or use this script
Just rename the txt file to *.bat and change the paths for your environment.

There’s a new SharePoint Blog : SharePoint in Pictures. A blog with diagrams for visualizing SharePoint as a development platform.

Great Idea.

http://blogs.msdn.com/b/sharepointpictures/

Gefunden bei David Salagunito.

SharePoint ermöglicht den (technischen!) Schritt über  Web 2.0 zum Enterprise 2.0: Portale, Blogs, Wikis, Personalisierbarkeit – kurz Anpassungsmöglichkeiten ohne Ende. Und genau da zeigt sich in der Praxis ein großes Problem. Wer SharePoint ohne weitere Rahmenvorgaben sich selbst bzw. den Endbenutzern überlässt, wird sich über kurz oder lang einer grenzenlosen Vielfalt an Portalen, Metadaten und Lösungen erfreuen. Oder aus Betriebs- und Organisationssicht an ihr verzweifeln.

Wichtig ist bei aller Individualisierung das organisatorische Ganze nicht aus den Augen zu verlieren. Ein Metadatum „Abteilung“ (z.B. für die Zuordnung von Dokumenten zu einer Organisationseinheit) sollte an einer Stelle zentral gepflegt und verwaltet werden. Die Gründe liegen auf der Hand: Wenn jedes Portal seine eigene Abteilungsstruktur pflegt führt das einerseits zu unnötiger Doppelverwaltung und andererseits zu nicht oder nur schwer wieder integrierbaren Insellösungen.

Wann aber ist eine Funktion oder ein Metadatum von globalem Interesse? Diese Entscheidung kann natürlich nicht immer im Vorfeld getroffen werden. Eine Organisation entwickelt sich weiter und vielleicht „reift“ etwas erst mit der Zeit zum „globalen Feature“.

Wichtig ist also nicht nur eine Bewertung von geplanten Lösungen, sondern auch eine regelmäßige Überprüfung der vorhanden. In der Literatur wird diese Aufgabe vom sog. SharePoint Governance Board (SPGB) wahrgenommen. Um den unterschiedlichen Aspekten Rechnung zu tragen, besteht diese Gremium idealerweise aus einem Vertreter des IT-Betriebs, der Fachabteilungen und der Organisation bzw. des Wissensmanagements. Das SPGB versteht sich dabei nicht als Kontrollinstanz, sondern vielmehr als Wegweiser. Es geht nicht primär darum, Lösungen zu verhindern oder Tools zu verbieten, sondern den Interessen und der Vision des gesamten Unternehmens gerecht zu werden. Das SPGB muss über alle Aktivitäten im SharePoint informiert sein, die nötige Kompetenz und vor allem auch gewisse Entscheidungsbefugnisse besitzen. Ziel ist, die „Kreativität“ der Endanwender ein wenig zu lenken, Prioritäten zu setzen und den Mehrwert durch Integration und strukturierten Datenfluss sicherzustellen.

Bin eben über ein gut 100 Seiten starkes eMagazine zu SharePoint 2010 gestolpert. Ist zwar schon ein paar Wochen alt, aber trotzdem lesenswert.

Schöne Ostertage für alle!

Fällt der Umgang mit den Ribbons (noch) schwer? Dann probiert doch mal den RibbonHero. Ein tolle spielerische Möglichkeit die Funktionsvielfalt der Office Programme zu entdecken. Und ganz ehrlich: Man stolpert so ganz nebenbei immer wieder über sehr interessante Goodies

Wer SharePoint mit Kerberos einrichten muss, der kennt vielleicht folgenden Fehler:

HTTP Error 401.1 – Unauthorized: Access is denied due to invalid credentials. Internet Information Services (IIS)

In meinem Fall lag es an falsch gesetzten SPNs.

Ein Kerberos Ticket wird normalerweise für einen bestimmten Dienst ausgestellt. Um einen Dienst zu identifizieren, muss ein eindeutiger Name (SPN) vergeben werden. Dieser Name muss bei dem Konto hinterlegt werden, unter welchem der Dienst ausgeführt wird.

In der SharePoint Welt heißt das: Unser Dienst ist die Webanwendung, die unter dem Account im zugehörigen ApplicationPool ausgeführt wird. Also muss hier der SPN hinterlegt werden. Und wie heißt nun dieser SPN? Klassische Antwort KDA (=kommt drauf an)

Um eine SharePoint Seite zu öffnen gibt man im Browser eine URL ein. Der Browser holt sich dann beim Key Distribution Center (KDC) ein Kerberos Ticket und muss dabei angeben, auf welchen SPN diese ausgestellt werden soll. Da der Browser sich sinnvollerweise nicht mit einem Popup meldet und den User dazu befragt, generiert er aus der eingegebenen URL den SPN. Beim IE kann man nun über einige Registry Keys einstellen, wie dies von statten geht.

So kann über die RegistryKey FEATURE_INCLUDE_PORT_IN_SPN_KB908209 und FEATURE_USE_CNAME_FOR_SPN_KB911149 eingestellt werden, ob die Portnummer bzw. der CNAME für den SPN verwendet werden soll. Untersucht habe ich das bisher für IE 6 und IE 7. Zu IE 8 (insbesondere auf Windows 7) habe ich keine validen Aussagen.

Beispiel:

URL der SharePoint Site ist: http://unserPortal:123/default.aspx, unserPortal ist ein CNAME und zeigt auf den Rechner mit Hostname Server1

Das kann sich auch durchaus nochmal unterscheiden, wenn ein Proxy verwendet wird.

Schwierig ist das festlegen der SPN auch deswegen, weil wir ja nicht nur an den Browser denken müssen. Wie verhalten sich andere Anwendungen, die mit SharePoint kommunizieren? z.B. Office, SPD, .NET Framework, Managemnt Tools usw ….

Zu diesem Thema empfehle ich auch den Beitrag von Michel Barnveld: The reason why KB911149 and KB908209 are not the solution!

Zumindest Office hat sich in unseren Tests auch der o.g. RegistryKey bedient und die Einstellungen jeweils berücksichtigt. Ansonsten muss man sich die Kerberos Logs anschauen und ausprobieren, welcher SPN angefragt wird …. Kling komisch, ist aber (leider) so.

Das Jahr hat gerade begonnen und schon wirft wieder ein großes Event seinen Schatten voraus. Im Rahmen der BASTA! finden wieder die SharePoint-Days statt. Die Tracks & Sessions findet man hier.

In diesem TechNet Artikel sind die nötigen Berechtigungen für die SharePoint Konten aufgelistet. Aus meiner Sicht fehlt hier ein Hinweis darauf, dass auch lokale Sicherheitsrichtlinien für Gruppen bzw. Konten gesetzt werden.

Beim Durchlaufen des Config-Wizards werden unter Windows Server 2008 z.B. die Gruppe WSS_WPG angelegt und die folgenden Sicherheitsrichtlinien zugeordnet:

- Impersonate a client after authentication
- Log on as a batch job

Achtung: In manchen Umgebungen werden diese Richtlinien zentral verwaltet und ggf. wieder überschrieben. Beim Anlegen einer neuen WebApplication in der CentralAdmin wird der angegebene Application Pool Account nur noch in die Gruppe WSS_WPG eingefügt, die eigentlichen Berechtigungen werden aber nicht mehr überprüft. Dies kann dazu führen, dass der Application Pool nicht gestartet werden kann (-> Service not available).

Ähnliches kann bei der Suche passieren: Falls die Suche nicht startet ist zu überprüfen, ob der Search Account über das Recht “Log on as a service” verfügt.

Wenn man WSPBuilder in Visual Studio nutzen möchte, aber ein deutsches (oder anders lokalisiertes) Betriebssystem drunter hat, wird das Add-in nicht gefunden.

Dann sucht man vergeblich nach diesem Kontextmenü :

Da hilft es Visual Studio den richtigen Pfad zum Add-in zu flüstern:

In Visual Studio > Tool > Option > Environment > Add-ins/Macro Security

und dort den Pfad zum Add-in eintragen. Für ein deutsches System bspws.

C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Microsoft\MSEnvShared\Addins

Visual Studio neu starten und schon ist das Kontextmenü da.

Den entscheidenden Hinweis habe ich hier gefunden:

http://sevcik.tk/2009/01/29/how-to-fix-unavailable-wspbuilder-menu-in-vs-2008.html/comment-page-1#comment-199