Wenn man InfoPath mit Forms Services benutzt, hat man oft mit Beschränkungen zu kämpfen, die sehr lästig sein können. So ist es z.B. aus HTML-Technischen Gründen nicht von Natur aus möglich, einem mehrzeiligen Eingabefeld eine Zeichenbeschränkung aufzuzwingen. Das Feld ist schlicht ausgegraut:



Das kann sehr nervig sein, wenn man die InfoPath Daten in eine Datenbank speichern möchte, und das Zielfeld nur eine begrenzte Länge hat. Es wäre schön, wenn man die Fehleingabe schon im Browser abfangen könnte.
Mit einem kleinen Kniff kann man dies jedoch auch für die mehrzeiligen Eingabefelder erreichen.
Dazu muss die Validierung für das betreffende Feld eingeschaltet werden: "Data Validation"



Für die Validierung wählt man ein eigenes "Custom Pattern", was letztendlich nichts anderes ist als eine Regular Expression:



Als Pattern wählt man dann einfach folgende RegEx:

(.|[\r\n]){0,255}



Wobei hier 255 Beispielhaft die maximale Anzahl der erlaubten Zeichen ist.
Dadurch darf jedes beliebige Zeichen, inklusive eines Zeilenumbruches eingegeben werden, und zwar mindestens 0-Mal, und maximal 255-Mal.
Der "ScreenTip" wird dann über der Box eingeblendet, und die Eingabebox ist wie gewohnt rot umrandet:

Eine bestehende WebApplication in MOSS, die unter http läuft, kann relativ einfach auf SSL umgestellt werden.
Über den folgenden Weg kann man seine Site umstellen und mit einem selbst generierten Zertifikat versehen (für Testzwecke).
Hat man später ein gültiges Zertifikat einer Zertifikatsstelle, tauscht man dieses einfach im IIS aus.
Hat man bereits ein Zertifikat, braucht man das Resource-Kit natürlich nicht zu installieren.

1. IISResource-Kit downloaden (iis60rkt.exe) und installieren

2. Zertifikat erzeugen und zur IIS Site hinzufügen:
c:\>selfssl /N:CN=*.<domainname.tld> /K:1024 /V:3650 /S:<IISSiteID> /P:443
z.B.:
c:\>selfssl /N:CN=*.example.com /K:1024 /V:3650 /S:1234567890 /P:443

3. Secure Bindings für die Webseite setzen:
In den Ordner wecheln, in dem die adsutil.vbs Datei liegt (z.B.: c:\Inetpub\AdminScripts)
c:\>cscript adsutil.vbs set /w3svc/<IISSiteID>/SecureBindings ":443:<Domain>"
z.B.:
c:\>cscript adsutil.vbs set /w3svc/12345567890/SecureBindings ":443:portal.example.com"
iisreset

4. c:\>iisreset

5. In der CentralAdministration die URL auf https:// umstellen (nur die URL ändern):



Quelle:
http://mcmsfaq.com/cs2/blogs/adrian_spe ... 7/205.aspx
http://www.plijnaer.nl/weblog/2007/08/m ... s-and.html

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)