in

SharePoint Blogs

The Best Place for SharePoint-related Blogs

odi's blog

  • Masterpage-Dateien und SharePoint Designer

    Bei der Entwicklung mit Masterpage-Dateien sollte man eines nie, nie, nie machen:

    Eine Masterpage-Datei, die im Dateisystem liegt (z.B. ans Bestandteil eines Features) mit dem SharePoint Designer editieren. Der Effekt ist grausam! Jede aspx-Datei, die diese Masterpage-Datei verwendet, wird eine Fehlermeldung "Datei nicht gefunden" verursachen. Und das, obwohl zunächst alle Dateien offensichtlich vorhanden sind.

    Was passiert also beim Editieren mit dem SharePoint Designer?

    Nun, er versucht einfach nur schlau zu sein. Wenn eine Datei aus dem Dateisystem geöffnet wird, dann untersucht der SharePoint Designer alle Pfad- und Dateiangaben, die in der Datei vorhanden sind. Und die Pfade, mit denen er nichts anfangen kann, die werden geändert !!! Der Effekt ist folgender:

    In den meisten Masterpage-Dateien wird im Kopf der Datei folgendes Fragment zu finden sein:

    <@Master language="C#"%>
    <%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
    <%@ Import Namespace="Microsoft.SharePoint" %>
    <%@ Import Namespace="Microsoft.SharePoint.ApplicationPages" %>
    <%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
    <%@ Register TagPrefix="wssuc" TagName="Welcome" src="~/_controltemplates/Welcome.ascx" %>
    <%@ Register TagPrefix="wssuc" TagName="DesignModeConsole" src="~/_controltemplates/DesignModeConsole.ascx" %>
    <HTML dir="<%$Resources:wss,multipages_direction_dir_value%>" runat="server" xmlns:o="urn:schemas-microsoft-com:office:office" __expr-val-dir="ltr">
    <HEAD runat="server">
    [...]

    Hier sind besonders die Register-Einträge zu beachten, die die Tagnames "Welcome" und "DesignModeConsole" definieren. Hier werden relative Pfade angegeben ("~/controltemplates/…"). Befindet sich die Datei im Dateisystem und wird dann mit dem SharePoint Designer bearbeitet und gespeichert, dann sieht das Fragment anschließend so aus:

    <@Master language="C#"%>
    <%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
    <%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Import Namespace="Microsoft.SharePoint" %>
    <%@ Import Namespace="Microsoft.SharePoint.ApplicationPages" %>
    <%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
    <%@ Register TagPrefix="wssuc" TagName="Welcome" src="_controltemplates/Welcome.ascx" %>
    <%@ Register TagPrefix="wssuc" TagName="DesignModeConsole" src="_controltemplates/DesignModeConsole.ascx" %>
    <HTML dir="<%$Resources:wss,multipages_direction_dir_value%>" runat="server" xmlns:o="urn:schemas-microsoft-com:office:office" __expr-val-dir="ltr">
    <HEAD runat="server">
    [...]

    Wie unschwer erkennbar ist, "optimiert" der SharePoint Designer ein wenig und entfernt aus den Pfadangaben den Teil "~/". Damit ist die Datei bei der Ausführung der Masterpage nicht mehr auffindbar, was zum Fehler "Datei nicht gefunden" führt.

    Daher, wenn eine Masterpage aus dem Dateisystem editiert werden soll, dann entweder den guten alten Notepad oder das Visual Studio verwenden.

  • SharePoint Services 3.0 und die Indizierung von MSG-Dateien

    Die SharePoint Services 3.0 stellen von sich aus keine Möglichkeit zur Verfügung, Inhalte von MSG-Dateien (gespeicherte Outlook-Mails) zu indizieren. Es gibt einige kostenpflichtige IFilter, aber über einen kleinen Umweg, lässt sich auch der MSG-IFilter für die Windows Desktop Search verwenden.
     
    1. Windows Desktop Search installieren
    Zuerst muss auf dem SharePoint-Rechner die Windows Desktop Search installiert werden. Das Installationspaket stellt Microsoft in seinem Downloadbereich zur Verfügung. Die Windows Desktop Suche ist notwendig, damit im nächsten Schritt der MSG-IFilter installiert werden kann.
     
    2. MSG-IFilter installieren
    Für die Windows Desktop Suche stellt Microsoft einen MSG-IFilter zur Verfügung. Das Installationspaket hierfür ist ebenfalls im Downloadbereich von Microsoft verfügbar.
     
    3. Änderungen in der Registrierdatebank
    Die Dateiendung und der IFilter müssen jetzt noch für die SharePoint-Suche registriert werden. Hierfür müssen in der Registrierdatenbank diese beiden Einträge gemacht werden (thanks to Gavin Adams Blog-entry for the info about the Outlook mime types):
     
    Windows Registry Editor Version 5.00
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\Filters\.msg]
    "Extension"="msg"
    "FileTypeBucket"=dword:00000001
    "MimeTypes"="application/vnd.ms-outlook"
     
    Windows Registry Editor Version 5.00
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.msg]
    @=hex(7):7b,00,34,00,30,00,33,00,39,00,62,00,33,00,32,00,36,00,2d,00,39,00,66,\
      00,32,00,37,00,2d,00,34,00,62,00,34,00,61,00,2d,00,62,00,34,00,36,00,30,00,\
      2d,00,34,00,37,00,61,00,30,00,63,00,36,00,61,00,33,00,39,00,64,00,35,00,63,\
      00,7d,00,00,00,00,00
     
    4. SharePoint-Suchdienst neu starten
    Damit die Änderungen in der Registrierdatenbank aktiv werden, muss der SharePoint-Suchdienst neu gestartet werden. Über ein Befehlsfenster werden die Kommandos
     
    NET STOP SPSEARCH
    NET START SPSEARCH
     
    ausgeführt.
     
    5. Vollständigen Crawl starten
    Damit auch bereits abgelegte MSG-Dateien indizeirt werden, muss ein vollständiger Crawl gestartet werden. Hierfür wird ein Befehlsfenster geöffnet und in das Verzeichns "C:\Programme\Gemeinsame Dateien\Microsoft Shared\Web Server Extensions\12\BIN" gewechselt hier wird
     
    STSADM -o spsearch -action fullcrawlstart
     
    ausgeführt.
     
    6. Windows Suche deaktivieren (optional)
    Die Windows Desktop Suche kann jetzt wieder aktiviert werden. Sie wurde nur benötigt, damit der IFilter von Microsoft installiert werden kann. Deaktivieren lässt sich der Dienst über die Verwaltung > Dienste.
     
  • Webpartseiten und Websitevorlagen

    Ich habe mich heute mal ein wenig mit der Erstellung von neuen Webpartseiten auseinandergesetzt, und es war wirklich eine Auseinandersetzung. Über die Websiteeinstellungen lassen sich neue Webpartseiten anlegen, diese Seiten haben nur den Nachteil, dass die Schnellstartleiste fehlt. Also, ab einfachsten die default.aspx im SharePoint Designer laden und unter einem anderen Namen abspeichern, dann habe ich ja eine neue Webpartseite. Gesagt getan, und die Seite war danach auch da und konnte verwendet werden. Ich habe dann auf diese Seite ein paar Webparts abgelegt und diese Webparts auch konfiguriert, u.a. soll bei Symbolleistentyp "Keine Symbolleiste" eingetragen sein. Meine Site also soweit zusammengestellt und dann als Vorlage in den Websitevorlagenkatalog gespeichert. Soweit so gut.

    Aus der Vorlage dann eine neue Site erstellt, auf die neue Webpartseite gegangen und aus allen Wolken gefallen. Der Symbolleistentyp war auf "Vollständige Symbolleiste" eingestellt. Also das Webpart nocheinmal konfiguriert, die Vorlage gespeichert, aus der Vorlage wieder eine Site angelegt: gleiches Ergebnis, der Symbolleistentyp passt wieder nicht.

    Wie ist die neue Webpartseite entstanden? Ich hatte die default.aspx im SharePoint Designer geöffnet und dort unter einem anderen Namen gespeichert. OK, dann gehen wir eben einen anderen Weg.

    Die Site über den SharePoint Designer geöffnet und die default.aspx kopiert. Nach meinem Verständnis sollte jetzt das Gleiche passieren wie bei dem vorherigen Versuch. Diese neue Kopie ebenfalls soweit zusammengestellt, wie ich es vorher schon gemacht hatte, u.a. auch den Symbolleistentyp eingestellt, und die Site dann wieder im Websitevorlagenkatalog gespeichert.

    Wieder eine Site angelegt, diesesmal mit der neuen Vorlage, auf die neue neue Webpartseite gegangen, und siehe da, der Symbolleistentyp passt.

    Was lässt sich jetzt aus diesen Erkenntnissen ableiten? Wenn eine neue Webpartseite angelegt werden soll, dann kopiere eine bestehende Seite über den SharePoint Designer. Beim Speichern unter einem anderen Namen scheint irgendetwas zu passieren (oder vielleicht auch nicht zu passieren).

  • Websitevorlagen in SharePoint v3.0

    Websitevorlagen sollen den Inhaltsadministrator u.a. dabei unterstützen, vordefinierte Strukturen zu schaffen, damit eine Site nicht gleich von Anfang an ein chaotisches Eigenleben entwickelt. Daher ist es recht angenehm, dass man zunächst eine Site so "zurecktzupfen" kann, wie sie aussehen soll, und anschließend über die Websiteeinstellungen im Katalog eine Vorlage ablegen kann. Wären da nicht drei in meinen Augen sehr unangenehme Dinge, von denen ich eigentlich zwei in die Kategorie "Fehler" einordnen würde.

    1. Symbolleistentyp geht verloren
    Eine der Eigenschaften, die für ein Webpart eingestellt werden können, ist der Symbolleistentyp. In einigen Fällen bietet es sich an, dass hier die Option "Keine Symbolleiste" ausgewählt wird, wodurch die Ausgabe "Neues Dokument hinzufügen" unterdrückt wird. Wird die Site als Vorlage gespeichert und dann basierend auf dieser Vorlage eine neue Site angelegt, dann wird der Symbolleistentype wieder auf "Übersichtssymbolleiste" umgestellt. Dieses Verhalten würde ich in die Kategorie "Fehler" einordnen.

    2. Standardwebparts gehen verloren
    In einer SharePoint-Site, die aus den Standard-Vorlagen (Teamwebsite, etc.) angelegt werden, stehen einige nützliche Webparts, wie z.B. das Inhalts-Editor-Webpart zur Verfügung. Wird eine Site als Template gespeichert, und dann mit STSADM -o addtemplate in den globalen Vorlagenkatalog aufgenommen, sodass die Vorlage auch für eine Site-Collection verwendet werden kann, dann fehlen genau diese Webparts, nachdem basierend auf der Vorlage eine neue Site-Collection angelegt wurde. Sie können zwar über "Auffüllen" wieder in den Webpartkatalog aufgenommen werden, aber das ist trotzdem ärgerlich, vor allem, wenn die Site-Collections automatisiert angelegt werden, also kein Administrator anschließend "auffüllen" kann. Auch dieses Verhalten würde ich in die Kategorie "Fehler" einordnen, wobei dies wie gesagt nur auftritt, wenn die Vorlage mit STSADM zugefügt wurde.

    3. Gruppen/Rollen werden nicht korrekt in die Vorlage übernommen
    Für mich gehört zu einer Vorlage auch, dass Vorbereitungen für die Berechtigungen gemacht werden können, also SharePoint-Gruppen angelegt und diese Gruppen in Listen und Bibliotheken verwendet werden können, sodass die Zugriffe entsprechend eingestellt werden können. Nicht immer dürfen die Teilnehmer einer Site wirklich in allen Listen und Bibliotheken schreiben. Jetzt zunächst die gute Nachricht: wird für eine Vorlage eine Rolle/Gruppe angelegt, dann steht diese Gruppe auch nach der Anwendung der Vorlage zur Verfügung. Die schlechte Nachricht: wurde eine Bibliothek oder Liste mit eigenen Berechtigungen konfiguriert, dann wird nach dem Anwenden der Vorlage wieder die Vererbung in Kraft gesetzt. D.h., die in der Vorlage eingestellten Berechtigungen in der Liste oder Bibliothek gehen verloren. Auch hier würde ich gern von einem "Fehler" sprechen, aber mit den richtigen Argumenten würde ich mich ja vielleicht auch überzeugen lassen, dass es sich eher um ein "Feature" handelt.

    Insgesamt wurden meine Hoffnungen, mit Websitevorlagen recht gut Grundstrukturen zu schaffen, drastisch gedämpft. Vielleicht habe ich ja die Latte auch einfach nur zu hoch gehängt, aber ärgern tue ich mich trotzdem.

     

  • WSS v3 und Suche in PDF-Dateien

    Zum Thema PDF-Suche und SharePoint v3.0 gibt es inzwischen reichlich Beiträge im Web. Nachdem sich Microsoft mit dem Artikel 927675 (http://support.microsoft.com/kb/927675/en-us) ebenfalls mit einem Betrag gemeldet hat, sollte das Thema eigentlich reichhaltig behandelt sein.

    Um die Einstellungen aus dem Microsoft-Artikel vornehmen zu können haben wir ein Tool erstellt, dass bei der Konfiguration helfen soll. Dieses Tool, samt kurzer Beschreibung liegt hier zum download.

    For all international readers:

    Searching in PDF-files in SharePoint Services v3.0 needs some editing in the registry as Microsoft has shown in article 927675 in the knowledge base. To check (and set) the settings for crawling PDF-files, we have made a small tool. This tool is free, you can download it here.

  • Datenimport, Ersteller und Erstellt-Datum

    Um Daten von einem SharePoint-Web in ein anderes SharePoint-Web zu transportieren, habe ich ein kleines Tool erstellt, mit dem der Inhalt einer Liste oder Bibliothek in eine XML-Datei exportiert werden kann. Hierbei werden alle Attribute eines Listeneintrags mitgenommen, auch wenn sie auf readonly gesetzt sind.

    Das gleiche Tool bietet mir die Möglichkeit, die Daten wieder zu importieren, wobei auch eine Mapping-Tabelle angegeben werden kann, wenn Feldnamen geändert wurden. Die Performance ist zwar nicht berauschend, aber man kann ja nicht alles haben. Mit diesem Tool haben wir unsere SharePoint-Installation von v2.0 nach v3.0 umgestellt.

    Eines ist bei einem solchen Import sehr unschön: die Information, wann ein Eintrag erstellt wurde, und durch wen er erstellt wurde wird von SharePoint automatisch gefüllt. Die Felder sind readonly, und auch wenn das readonly-Attribut an den betreffenden Feldern umgestellt wird, schreibt SharePoint gnadenlos seine Informationen in die Felder. Damit kann ich zwar schön sehen wann ich importiert habe, aber als Ersteller ist jetzt auch immer der Administrator eingetragen. Wenn die Entstehung der Daten zurückverfolgt werden soll, dann ist diese Arbeitsweise sehr störend.

    Ich werde noch ein wenig darüber nachdenken, aber ich glaube im Moment, dafür gibt es keine vernünftige Lösung (außer direkt in die Datenbank zu schreiben, was ich eigentlich vermeiden will).

  • Logging in SharePoint v3

    Einer unserer Entwickler hat in den letzten Tagen ein wenig schlechte Laune bekommen, weil die Festplatte in seinem Virtual PC Image (wir entwickeln in diesen Images, weil dann leichter zwischen verschiedenen Umgebungen umgeschaltet werden kann) voll wurde, und er noch nicht einmal mehr die Sicherheits-Patches von Microsoft installieren konnte. Er ist gerade dabei unsere Anwendung von SharePoint v2 auf SharePoint v3 umzustellen, und arbeitet dafür mit der Beta 2 bzw. dem B2TR.

    Irgendwie konnte ich mir nicht vorstellen, dass die Festplatte so schnell voll wird, zumal eine Installation von Office 2007 B2TR, Sharepoint Designer 2007 B2TR und Windows SharePoint Services 2007 B2TR inkl. Windows Server 2003, SQL Server 2005 und Visual Studio 2005 ca. 11 GB belegt. Also haben wir uns die Verzeichnisse in seinem Virtual PC mal genauer angesehen, und siehe da, in "%CommonProgramFiles%\Microsoft Shared\web server extensions\12\LOGS" waren ca. 4 GB Log-Dateien enthalten. Für diese Datenmenge hat es nur wenige Tage gebraucht.

    Ich habe noch keinen Schalter gefunden, mit dem die Log-Dateien komplett abgeschaltet werden können, aber über die "SharePoint 3.0-Zentraladministration" kann unter Vorgänge > Protokollierung und Berichterstellung > Diagnoseprotokollierung im Abschnitt "Ablaufverfolgungsprotokoll" die Anzahl der Protokolldateien und auch die Anzahl der Minuten je Protokolldatei eingestellt werden. Werden diese Werte recht klein gewählt, werden zwar immer noch Log-Dateien angelegt und gefüllt, aber die Datenmenge wird deutlich reduziert.

    Ich wünsche mir, dass Microsoft dies in der RTM von Hause aus reduziert, sodass nicht bei jeder Installation diese Log-Einstellungen geändert werden müssen.

     

  • Code Access Security mit Solutions in SharePoint v3

    Ich will mich hier zwar überwiegend mit der Administration von SharePoint auseinandersetzen, aber man muss auch über den Tellerrand schauen. In diesem Zusammenhang stolpert man unweigerlich über die "Code Access Security" (CAS), die für Webparts wichtig ist, die irgendwie auf Resourcen (z.B. das Active Directory) zugreifen wollen. Mit SharePoint v2 bricht man sich so ziemlich die Finger, auch wenn es recht gute Artikel und Blogs dazu gibt. Mit SharePoint v3 soll jetzt alles besser werden, und Maurice Prather hat hierzu einen wirklich guten Artikel verfasst. Das schöne an diesem neuen Feature in SharePoint v3: jetzt kann der Entwickler sein Webpart (seine Solution) verpacken, und muss sich um die korrekten Einstellungen kümmern. Wir Admins brauchen es nur noch zu installieren smile. Nichts mehr mit web.config editieren, oder gar den Trust Level auf Full setzen.

     

  • Cannot connect to the configuration database

    Mitch Milam hat einen interessanten Artikel verfasst, der sich mit der Problematik beschäftigt, dass beim Zugriff via STSADM eine Fehlermeldung erscheint, dass auf die Konfigurationsdatenbank nicht zugegriffen werden kann.

    Grob zusammengefasst: der Benutzer, der mit STSADM arbeitet braucht Zugriffsrechte auf den SQL Server auf dem die Datenbank(en) liegt.

  • Sichern einer SharePoint Datenbank

    Wer sich bei Microsoft die Windows SharePoint Services (WSS) herunterlädt, erhält für die Datenhaltung eine Microsoft Data Engine (MSDE) mitgeliefert, eigentlich ein vollwertiger SQL Server 2000, der aber zumindest um seine grafischen Administrationswerkzeuge beraubt wurde. In der gleichen Situation ist der Administrator eines Windows 2003 Small Business Server.

    Wie mache ich jetzt am geschicktesten ein Backup von den SQL-Datenbanken? Über STSADM regelmäßig eine Sicherung einer Site zu machen, ist sicherlich eine Option (ich werde mich dazu demnächst noch äußern), aber spätestens, wenn es mehrere Sites gibt, und vor allem nicht kontrolliert werden kann, wie und wann neue Sites angelegt werden, wird es mit einer Sicherung via STSADM schwierig.

    Eine (aus Administrator-Sicht vernünftige) Variante ist die Sicherung der SQL-Datenbanken. Da mit der MSDE wenigstens das Administrationswerkzeug OSQL mitgeliefert wird, sind wir immerhin in der Lage, den SQL Server mit Befehlen zu füttern. Da bietet es sich doch an, eine Batchdatei anzufertigen, die regelmäßig eine Sicherung einer SQL-Datenbank anfertigt. Ein Batch zum Sichern kann so aussehen:

    @ECHO OFF

    REM ***********************************************************************************
    REM
    REM DBBACKUP
    REM ========
    REM
    REM written by SPO/odi, 07/2006
    REM
    REM Backup the database or the transaction log of a SQL Server database using OSQL.
    REM Runs also with MSDE and WMSDE.
    REM
    REM ***********************************************************************************

    ECHO.
    ECHO DBBACKUP
    ECHO --------
    ECHO.
    ECHO by SPO/odi, 07/2006
    ECHO.

    IF "%1"=="" GOTO SYNTAX
    IF "%2"=="" GOTO SYNTAX
    IF "%3"=="" GOTO SYNTAX
    IF "%4"=="" GOTO SYNTAX

    IF /I "%1"=="DB" GOTO BACKUP_DB
    IF /I "%1"=="TRANS" GOTO BACKUP_TRANS

    GOTO SYNTAX

    :BACKUP_DB

    SET DATABASE=%2
    SET BACKUPPATH=%3
    SET SERVER=%4

    SET BACKUPFILE=%BACKUPPATH%\%DATABASE%.bak

    SET BACKUPFILE=%BACKUPFILE:[=%
    SET BACKUPFILE=%BACKUPFILE:]=%

    IF "%SERVER%"=="" GOTO BACKUP_DB_NO_INSTANCE

    OSQL -E -S %SERVER% -Q "Backup Database %DATABASE% to disk='%BACKUPFILE%' with init"

    GOTO ENDE

    :BACKUP_DB_NO_INSTANCE

    OSQL -E -Q "Backup Database %DATABASE% to disk='%BACKUPFILE%' with init"

    GOTO ENDE

    :BACKUP_TRANS

    SET DATABASE=%2
    SET BACKUPPATH=%3
    SET SERVER=%4

    SET BACKUPFILE=%BACKUPPATH%\%DATABASE%.trn

    SET BACKUPFILE=%BACKUPFILE:[=%
    SET BACKUPFILE=%BACKUPFILE:]=%

    IF "%SERVER%"=="" GOTO BACKUP_TRANS_NO_INSTANCE

    OSQL -E -S %SERVER% -Q "Backup Transaction %DATABASE% to disk='%BACKUPFILE%' with init"

    GOTO ENDE

    :BACKUP_TRANS_NO_INSTANCE

    OSQL -E -Q "Backup Transaction %DATABASE% to disk='%BACKUPFILE%' with init"

    GOTO ENDE

    :SYNTAX

    ECHO Syntax:
    ECHO.
    ECHO DBBACKUP DB database backuppath servername : backup the database
    ECHO.
    ECHO DBBACKUP TRANS database backuppath servername : backup the transaction log
    ECHO.
    ECHO Example:
    ECHO   DBBACKUP DB master c:\backup myserver\sharepoint
    ECHO.
    ECHO   Will backup the database 'master' from the SQL Server at 'myserver\sharepoint'
    ECHO   to the directory 'c:\backup'.
    ECHO.
    ECHO If the databasename contains special characters like '-', use brackets around the
    ECHO databasename ([my-db]).
    ECHO.
    :ENDE

    SET DATABASE=
    SET BACKUPPATH=
    SET BACKUPFILE=
    SET SERVER=

    Die Wiederherstellung muss natürlich genauso funktionieren. Eine Batchdatei für die Wiederherstellung so gesicherter Datenbanken, kann wie folgt aussehen:

    @ECHO OFF

    REM ***********************************************************************************
    REM
    REM DBRESTORE
    REM =========
    REM
    REM written by SPO/odi, 07/2006
    REM
    REM Backup the database or the transaction log of a SQL Server database using OSQL.
    REM Runs also with MSDE and WMSDE.
    REM
    REM ***********************************************************************************

    ECHO.
    ECHO DBRESTORE
    ECHO ---------
    ECHO.
    ECHO by SPO/odi, 07/2006
    ECHO.

    IF "%1"=="" GOTO SYNTAX
    IF "%2"=="" GOTO SYNTAX
    IF "%2"=="" GOTO SYNTAX

    SET DATABASE=%1
    SET RESTOREPATH=%2
    SET SERVER=%3

    IF "%SERVER%"=="" SET SERVER=COMPUTERNAME

    SET RESTOREFILE_DB=%RESTOREPATH%\%DATABASE%.bak
    SET RESTOREFILE_TRN=%RESTOREPATH%\%DATABASE%.trn

    SET RESTOREFILE_DB=%RESTOREFILE_DB:[=%
    SET RESTOREFILE_DB=%RESTOREFILE_DB:]=%

    SET RESTOREFILE_TRN=%RESTOREFILE_TRN:[=%
    SET RESTOREFILE_TRN=%RESTOREFILE_TRN:]=%

    IF EXIST %RESTOREFILE_TRN% GOTO RESTORE_WITH_TRN

    ECHO Restore database %DATABASE% ...
    ECHO.

    OSQL -E -S %SERVER% -Q "Restore Database %DATABASE% from disk='%RESTOREFILE_DB%' with recovery"

    GOTO ENDE

    :RESTORE_WITH_TRN

    ECHO Restore database and transaction log for %DATABASE% ...
    ECHO.

    OSQL -E -S %SERVER% -Q "Restore Database %DATABASE% from disk='%RESTOREFILE_DB%' with norecovery"
    OSQL -E -S %SERVER% -Q "Restore Log %DATABASE% from disk='%RESTOREFILE_TRN%' with recovery"

    GOTO ENDE

    :SYNTAX

    ECHO The script will look into the backuppath. If only a file named {database}.bak
    ECHO is found, just the database will be restored. If also a file named
    ECHO {database}.trn is found, the database and the transaction log are restored.
    ECHO.
    ECHO Syntax:
    ECHO.
    ECHO DBRESTORE database backuppath servername : restore the database
    ECHO.
    ECHO.
    ECHO Example:
    ECHO   DBRESTORE master c:\backup myserver\sharepoint
    ECHO.
    ECHO   Will restorethe database 'master' on the SQL Server at 'myserver\sharepoint'
    ECHO   from directory 'c:\backup'.
    ECHO.
    ECHO If the databasename contains special characters like '-', use brackets around the
    ECHO databasename ([my-db]).
    ECHO.

    :ENDE

    SET DATABASE=
    SET RESTOREPATH=
    SET RESTOREFILE_DB=
    SET RESTOREFILE_TRN=

    Mit Hilfe der Geplanten Tasks der Systemsteuerung kann so ein regelmäßiges Backup der Datenbank angelegt werden. Wenn z.B. auf einem Windows 2003 Small Business Server mit diesen Hilfsmitteln die SharePoint-Datenbank gesichert wird, dann kann die Sicherungsdatei mit dem normalen Datei-Backup auf ein Band geschrieben werden.

     


Need SharePoint Training? Attend a SharePoint Bootcamp!

Posts (c) their respective authors. Everything else (c) 2007 SharePoint Experts