Unter Umständen kann es beim Versuch, ein Feature für eine Site Collection zu aktivieren, zu einer Access denied Fehlermeldung kommen. Insbesondere wenn man das Feature
Office SharePoint Server Publishing Infrastructure
aktivieren möchte.

Ursache sind falsche Berechtigungen der Application Pool User, die oft bei einer SharePoint Installation mit 8-10 verschiedenen Minimal Rights Usern Ärger bereiten. Je mehr man sich bemüht alles richtig zu machen und möglichst viele verschiedene AD User für alle Bereiche während der Installation anzulegen, desto schlimmer wird es später...

Um das Feature zu aktivieren, kann man entweder dem Application Pool User, unter dem die aktuelle WebApplication läuft, Lese/Schreibrechte auf die Datenbank der Central Administration geben, oder man tauscht den User kurz gegen einen anderen aus.
Am besten ermittelt man den Benutzer der Central Administration, indem man sich im IIS die Eigenschaften der CA Webseite anschaut, und den Benutzer unter dem Karteireiter "Identity" herauskopiert.
(Das Passwort sollte man natürlich kennen)



Diesen User trägt man dann als Identity für seine andere WebApplciation ein, und führt einen IISReset durch. Danach sollte man das Feature problemlos aktivieren können. Anschließend setzt man den alten AppPool User einfach wieder zurück und lässt nochmals einen IISReset laufen.

Wer schon einmal versucht hat, die Daten eines InfoPath Formulars über einen Webservice in eine Datenbank zu schreiben, wird sicherlich auch versucht haben, den Datentyp der ursprünglichen XML-Felder zu bestimmen um ggf. Konvertierungen durchzuführen.
Leider erhält man beim Versuch, den Datentyp per Code zu ermitteln, immer String als Ergebnis.
Ein Blick auf das XML eines XPathNavigator Objektes einer DataSource verrät, dass hier auch gar keine Datentypen hinterlegt sind, und diese auch folglich nicht ausgelesen werden können. Die gesamte Schema-Information befindet sich nämlich in der MySchema.xsd Datei, die sch z.B. in der fertigen .xsn des Formulars befindet.

Um den Datentyp zur Laufzeit dennoch ermitteln zu können, kann man über die OpenFileFromPackage Methode des Template Objekts auf die MySchema.xsd zugreifen:

public void pbStart_Clicked(object sender, ClickedEventArgs e)
{
string sType = "";
XmlDocument doc = new XmlDocument();
doc.Load(this.Template.OpenFileFromPackage("myschema.xsd"));
XmlNamespaceManager nsmgr = new XmlNamespaceManager(doc.NameTable);
nsmgr.AddNamespace("xsd", "http://www.w3.org/2001/XMLSchema");
XmlNodeList list = doc.SelectNodes("//xsd:element[@name='Geburtstag']", nsmgr);
sType = list.Item(0).Attributes.GetNamedItem("type").Value;
doc = null;
}


Danke an Daniel, der diesen Weg herausgefunden hat!

Immer wieder kommt es bei Installieren/Uploaden von InfoPath Formularen in SharePoint zu dem Phänomen, dass der Status auf Installing, Upgrading oder Deleting stehen bleibt.
Das Formular ist dann nicht nutzbar und es dauert dann ein oder mehrere Stunden, bis das Formular in den Status Ready übergeht - ein Phänomen, dass es zusätzlich zu der Sommerzeit-Problematik zu geben scheint.
Ursache ist scheinbar ein Fehler in der Routine, die den Startpunkt für einen solchen Job festlegt: Liegt dieser eininge Stunden in der Zukunft, muss man eben so lange warten, bis dieser Zeitpunkt erreicht ist...

Es scheint allerdings dafür einen Workaround zu geben, indem man SharePoint zwingt, die "One-Time"-Jobs sofort auszuführen:

stsadm.exe -o execadmsvcjobs

Eine wirklich wichtige Information, meine ich!
Gefunden unter:

http://www.sharepointblogs.com/spfromscratch/

(Geändert 04.06.2007)

Hat man einmal in all seinen InfoPath Formularen Änderungen vorgenommen und sie publiziert, muss man sie immer noch einzeln in der Central Administration uploaden, was ziemlich mühsam sein kann.

Mit stsadm.exe und dem folgenden Batch-Script geht das jedoch viel einfacher und schneller:

@echo off
echo Starting form upload! This may take a while...
echo _______________________________________________
echo.
if "%1"=="" goto end
:start
echo Uploading: %1
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm" -o upgradeformtemplate -filename %1
SHIFT
if "%1"=="" goto end
goto start
:end
echo _______________________________________________
echo.
echo OK, all form templates have been uploaded!
pause


Hierzu aus dem Code z.B. eine MassUpload.bat Datei erstellen und in den SendTo Ordner legen. (z.B.: C:\Documents and Settings\Administrator\SendTo)
Die gewünschten .xsn-Dateien markieren und SendTo -> MassUpload.bat wählen.

Alle markierten InfoPath Formulare werden nun der Reihe nach installiert, was allerdings auch seine Zeit dauert... Diese Zeit kann man jedoch sinnvoll anderweitig nutzen :)

Nachtrag:
Damit das Script funktioniert müssen die Formulare bereits in SharePoint hochgeladen worden sein, da hier nur ein upgradeformtemplate durchgefürt wird. Für neue Formulare müsste der Parameter durch uploadformtemplate ersetzt werden.

Es sieht ja ganz schick aus, besonders im Dunkeln, aber manchmal kann man sich schwer konzentrieren, wenn all die Lichter des Frühjahrs-DOMs vor dem Bürofenster blinken, und der Fahrgeschäftsbetreiber zum 798. Mal seinen Standardspruch ins Mikrofon grunzt.



(Wer es nicht kennt: Der Hamburger DOM ist ein sehr großes Volksfest (Kirmes, Jahrmarkt, Rummel) mitten in Hamburg und direkt vor unserem Bürogebäude.)