Fehler bei Convert-SPWebApplication in SharePoint 2013

Wer nach der Installation von Service Pack 1 in SharePoint 2013 versucht, eine Datenbank von SharePoint 2010 anzuhängen und danach in den Claims-Mode zu konvertieren, könnte eine Überraschung erleben.

Normalerweise hängt man die Datenbank mit Mount-SPContentDatabase an, SharePoint migriert dann das Datenbankschema und danach kann man mittels Convert-SPWebApplication „[URL]“ –To Claims –RetainPermissions die Benutzernamen migrieren lassen.

Sollte bei diesem Vorgang die Nachfrage nach eine derzeit im Technet undokumentierten Schalter „-From“ erscheinen, muss dort der Wert „Legacy“ eingegeben werden. Es handelt sich hierbei um eine neue Option. Allerdings hat die Sache einen Haken: Die Benutzermigration funktioniert in dieser Variante noch nicht, es handelt sich hierbei um einen Bug.

Wer das Kommando benötigt, muss zuvor das Cumulative Update vom Juni 2014 installieren, damit ist der Fehler behoben und die Benutzernamenmigration funktioniert wieder einwandfrei. Alternativ kann die Datenbank natürlich auch schon in SharePoint 2010 in den Claims-Modus migriert werden.

Quo vadis, SharePoint?

Nach der SharePoint-Konferenz in Las Vegas gab es viele Spekulationen und Gerüchte über die Zukunft von SharePoint. Vor allem ein Beitrag in der Computerwoche hat sehr viele Diskussionen ausgelöst, was denn nun in Zukunft mit OnPremise-Umgebungen von SharePoint passieren wird. Auch in meinem Kundenkreis hat dieser Beitrag für große Unsicherheit gesorgt. Daher habe ich mich entschlossen, meine persönliche Sichtweise auf das Thema in diesem Beitrag niederzuschreiben.

SharePoint Conference 2014

Ja, die SharePoint Conference in Las Vegas war sehr cloud-lastig, vor allem, wenn man sich nur die Tags der jeweiligen Session anschaut. Bei einem Blick auf den Inhalt wird aber schnell klar, dass viele der Sessions auch Funktionen zeigen, die man auch OnPremise nutzen kann. SharePoint 2013 setzt sehr stark auf JavaScript und die Schnittstellen sind in beiden Welten nutzbar.

Ankündigungen

Jeff Teper hat auf der SharePoint Conference für 2015 die nächste OnPremise-Version von SharePoint angekündigt. Richtig ist auch, dass Kunden empfohlen wird, in Richtung Cloud zu gehen, aber ein Großteil der Kunden wird diesem Trend in den nächsten 5-8 Jahren sicher nicht folgen, dafür sind die Investitionen in die lokale Infrastruktur derzeit noch zu präsent und die Bedenken seitens Datenschutz noch zu groß.

Doch auch bei diese Ankündigung wurde wieder viel spekuliert und interpretiert: Jeff Teper habe nur die nächste Version angekündigt und nichts darüber hinaus verlauten lassen. Warum sollte er auch? In den letzten Jahren hat sich Microsoft etwas verhaltener bei den Roadmaps gezeigt und bei den kommenden Funktionen. Die nächste Version ist für nächstes Jahr angekündigt, man denke nur an das Jahr 2012, als SharePoint 2013 angekündigt wurde. Davor war auch relativ wenig an die Öffentlichkeit gedrungen, allen TAP-Kunden wurde zudem ein NDA auferlegt. Warum sollte das diesmal anders sein? Und wenn es nichts Neues zu berichten gibt, warum sollten sich die meisten Sessions mit OnPremise beschäftigen?

Die Zukunft und meine persönliche Meinung

Die Frage bleibt also, was uns die Zukunft bringen wird. Und genau da weiß Microsoft auch nur, wie es bis in 2-3 Jahren aussehen wird. Und darüber hinaus wird es von den Kunden enschieden. Man erinnere sich nur an die Ankündigung zu Exchange 2007, dass die Public Folder aus einer der nächsten Version verschwinden werden. Der Aufschrei der Kunden war enorm und zu was hat es geführt? Public Folder werden auch in Exchang 2013 unterstützt. Sie werden zwar nicht mehr groß weiter entwickelt, aber sie sind immer noch da.

Doch bei SharePoint sieht das sogar noch anders aus: SharePoint als Produkt ist ein zentraler Bestandteil von Office 365. Somit erhält Microsoft quasi fast als “Abfallprodukt” eine OnPremise-Version für Endkunden. Somit können beide Welten wunderbar bedient werden. Wieso sollte man dies in Zukunft nicht nutzen und durch eine Abkündigung einen Teil der Kunden verlieren? Das dürfte Microsoft beim vormals umsatzstärksten Produkt nicht riskieren wollen.

Doch eines ist auch klar: Der komplette Funktionsumfang von SharePoint Online wir sich lokal nicht realisieren lassen. Schon heute sehen wir die Hardware- und Infrastrukturanforderungen von SharePoint 2013 als ein nicht ganz unbedeutenden Faktor bei Projekten. Die Ressourcenanforderungen sind bereits immens und dazu kommen die zusätzlichen Produkte drum herum, die installiert, überwacht und gewartet werden müssen (Workflow Services, Office Web Apps, Distributed Cache, usw.). In der nächsten Version werden wir sicher nicht alle Funktionen aus der Cloud seien, weil sie einfach mit den derzeitigen lokalen Infrastrukturen nicht abbildbar sind, z.B. einige Teile von Power BI wie Power Q&A.

Und genau an diesen Punkten werden wir in den nächsten Jahren sicher auch vermehrt Hybrid-Umgebungen sehen, die das beste aus beiden Welten integrieren wollen. Wo dann der Schwerpunkt sein wird, wird von Kunde zu Kunde unterschiedlich sein. Und genau dieses Verhalten wird auch langfristig zeigen, in welche Richtung Microsoft und auch andere Hersteller gehen müssen.

SPC 2014: Wie geht es weiter nach dem Ende von InfoPath?

Vor wenigen Wochen hat Microsoft öffentlich bekannt gegeben, dass es bei InfoPath keine Weiterentwicklung mehr geben wird, das Produkt wird eingestellt. Zwar wird die jetzige Version bis 2023 voll unterstützt, jedoch kann es natürlich sein, dass bereits in der für nächstes Jahr angekündigten neuen SharePoint-Version für on premise die Unterstützung schwindet, z.B. in Form der Forms Services.

 
 

Für die SharePoint Conference hat man eine Ankündigung eines Nachfolgers versprochen, allerdings sind die Meinungen nach der Session gemischt. InfoPath wird nicht durch ein Nachfolgeprodukt ersetzt, sondern durch eine Reihe neuer Technologien, von denen die meisten auf Access basieren und die Funktionen auch noch nicht vollumfänglich definiert sind. Microsoft ruft unter http://officeforms.uservoice.com/ dazu auf, Anregungen einzureichen und darüber abzustimmen, welche Funktionen in Zukunft gefordert sind.

 
 

Excel Surveys (aka FoSS)

Excel Surveys (oder Forms on top of Spread Sheets) sind bereits in Office 2013 verfügbar und erlauben das Erstellen von SharePoint-Umfragen mit Hilfe von Excel 2013. Dies funktioniert bereits in SharePoint 2013 on premises und wird in SharePoint Online bald auch verfügbar sein.

 
 

Forms on top of SharePoint Lists (FoSL)

FoSL wird eine neue webbasierte Technologie, die das Anpassen von Formularen in SharePoint im Browser direkt ermöglichen soll. Derzeit befindet sich die Technologie noch in Entwicklung und ist noch nicht einmal feature-complete. Die Funktion erlaubt es wie beim Modifizieren des Formulars mit Hilfe von InfoPath das Eingabe- und Anzeigeformular zu bearbeiten, hier jedoch im Browser.

Die Technologie basiert auf den Access Services und ist derzeit in einem sehr frühen Stadium. Die Demo in der Session war daher sehr dünn. In dieser Form wird es wahrscheinlich im Sommer in SharePoint Online bereitgestellt werden. Wenigstens sollen die meisten Feldtypen wie auch Nachschlagefelder und sogar kaskadierte Drop-Down-Felder unterstützt werden. Anfang 2015 sollen dann Regelfunktionen, Anzeigen/Verstecken von Bereichen, Unterstützung mobiler Geräte und Profilinformationen folgen. Weiterhin stehen für später WebService-Aufrufe, Enterprise-Daten und eSignature auf der Agenda. Wir sind gespannt, wie das tatsächlich aussehen wird.

 
 

Structured Documents

Oftmals werden in Unternehmen Formulare in Word generiert und ausgefüllt, damit man sie einfach drucken, in PDF umwandeln, archivieren und dergleichen kann. Hier soll zum Ende des Jahres vom Word Team eine Ankündigung gemacht werden, welche Änderungen und neuen Funktionen zukünftige Word Versionen bringen werden, aber derzeit gibt es hier gar nichts zu berichten.

 
 

App Forms

Hierauf konzentriert sich Microsoft offensichtlich am meisten. Die App Forms, die mit den Access Services erstellt werden, stellen die Zukunftstechnologie für Formulare in SharePoint OnPremise und Online dar. Also: Revival of Access. Die Access Services waren bereits in SharePoint 2010 dabei und nicht sonderlich beliebt, wir werden sehen, ob Microsoft das Ruder hier Herumreißen kann und einen deutlichen Mehrwert in allen Bereichen durch diese Technologie bieten kann oder ob der Begriff “Access” schon für lange Gesichter bei den Kunden sorgt.

 
 

Fazit

Ich bin sehr skeptisch bezogen auf die Ersatzprodukte von InfoPath. InfoPath war dermaßen mächtig und flexibel einsetzbar, dass es schwer wird mit solchen Ankündigungen hier das Vertrauen der Nutzer von InfoPath hoch zu halten. Klar, war es teilweise schwer damit umzugehen und einige Dinge funktionierten auch nicht so richtig, aber es kam – mal abgesehen von manchen Drittherstellerlösungen – nichts an die Möglichkeiten von InfoPath heran.

SPC 2014: Identity Federation, Load Testing und Power BI

Der Dienstag wurde für mich von Spencer Harbor mit einem Vortrag zur Identity Federation für Office 365 mit Windows Azure Active Directory eröffnet. Zunächst einmal stellte er klar, dass man Identity Mangement benötigt, sobald man SharePoint im Einsatz hat. Wer schon einmal mit Organisationsstrukturen in Genehmigungsprozessen, der Personensuche oder einer einfachen Auflistung von Mitarbeitern einer Abteilung in SharePoint zu tun hatte, weiß genau, wovon Spencer Harbar hier spricht. Und der technische Teil dieses Managements macht gerade einmal 10% aus, der Rest sind politische Themen innerhalb des Unternehmens.

 
 

Technisch zeigte Spencer dann wie man mit Hilfe von Windows Azure eine hochverfügbare Infrastruktur für die Identity Federation aufbauen kann. Wer eine solche haben möchte, muss mit insgesamt sieben Servern (2x ADFS Proxy, 2x ADFS, 2x SQL Server und 1x DirSync) eine ganze Reihe an Maschinen bereitstellen und warten. Diese sind in Windows Azure eventuell nicht weniger verfügbar und es ergibt sich unter Umständen auch ein Vorteil bei der Bandbreite für Internet-Clients. Die Maschinen bleiben trotzdem Teil der internen Domäne und kommunizieren über eine verschlüsselte VPN-Verbindung mit dem eigenen Netzwerk.

 
 

Das größte Problem bei der Identity Federation ergibt sich jedoch aus der Domänenstruktur: Wer eine größere Anzahl an Domänen oder sogar Forests hat oder dessen Domäne über eine nicht öffentlich verifizierbare Adresse verfügt (.local) muss besondere Wege gehen: Im ersten Fall wird ein separater FIM-Server benötigt, im zweiten muss der UPN der Benutzeraccounts entsprechend angepasst werden.

 
 

Weiter ging es mit einem sehr unterhaltsamen Beitrag von Shane Young und Todd Klindt, die zeigten, wie einfach Load Testing von SharePoint 2013 mit Visual Studio 2013 auch für Nichtentwickler sein kann. Sie unterschieden dabei auch zweckmäßig den Performance-Test, Last-Test und Stress-Test voneinander und wie diese umsetzbar sind, um beispielsweise zu bestimmen bis zu welcher Anzahl Benutzer die Farm ausgelegt ist und wo der Schwachpunkt liegt.

 
 

Den Abschluss bildete an diesem Tag für mich ein Vortrag über Power BI für IT Professionals. Matt Mason zeigte in diesem Vortrag die Mächtigkeit von Power BI in Office 365, indem er verschiedene Kennzahlen mit Hilfe von Power Query in Excel importierte, mit Power Pivot das Datenmodell erstellte, mit Power View und Power Map als Diagramm und als Landkarte visualisierte und diese dann auf Office 365 veröffentlichte. Dort lassen sich dann anhand der Datenquellen mittels Power Q&A menschliche Abfragen formulieren, um andere Visualisierungen zu erhalten, beispielsweise “issues by nr of tenants and priority”. Power Q&A erstellt dann eine passende Ansicht dieser strukturierten Datenquelle. Voraussetzung ist natürlich eine gute Datenmodellierung, damit Q&A die Begrifflichkeiten auch entsprechenden Dateneigenschaften zuordnen kann.

SPC 2014: Upgrade, Migration und Performance

Montagnachmittag hatte ich noch zwei Sessions besucht. Zunächst den Vortrag zu Upgrade und Migration auf SharePoint 2013 und Office 365 von Dan Holme. Er ist weniger auf die technischen Feinheiten, als auf die Business-Entscheidungen dahinter eingegangen. Sehr richtig fand ich die Aussage: “Soll ich auf SharePoint 2013 bzw. In die Cloud migrieren? – Nein!”. Denn im Gründe muss eine Änderung einen Business Value haben und darf kein Selbstzweck haben. Eine weitere Empfehlung von ihm: möglichst früh die neuen Produkte parallel einführen und für die Zwecke nutzen, die dort besser gehen. Im Grunde genommen bei SharePoint 2013 eben alle Workloads.

Dies hat natürlich zur Folge, dass man zwei Umgebungen betreuen muss, daher muss man sich die Frage stellen, ob eine Migration der alten Inhalte dann nicht doch einen Business Value hat.

Eine weitere Absage erteilte er der weit verbreiteten Mär, dass man bei neuen Produkten besser bis Service Pack 1 warten sollte. Mal davon abgesehen, dass diese Wartezeit bei SharePoint 2013 nun vorüber ist, werden die neuen Releases bereits bei Microsoft mit Millionen von Benutzern getestet, im Rahmen von Office 365. wir haben es also mit’m feiner völlig anderen Test zu tun, der die Bugfreiheit enorm erhöht.

Beim zweiten Vortrag von Ryan Campbell ging es um Advanced Performance Analysis. Er stellte anhand eines Kundenszenarios mit einer sehr großen SharePoint Farm dar, mit welchen Mitteln er beim Kunden Flaschenhälse entdeckt hatte.

Hierzu sammelte er 400GB Rohdaten von IiS Logs, Performance Countern, TraceRoutes, ULS Logs und so weiter und analysierte diese per SQL Server, Power BI und Excel, um Grafiken zu erstellen

Das Resultat der Untersuchung ergab folgende Action Items:

• Abschalten vergessener Überwachungsfunktionen
• Erhöhen der Dateianzahl der TempDB
• RAM-Erweiterung
• Setzen von MAXDOP im SQL Server auf 1
• Erhöhen der Netzwerkbandbreite bei einigen Verbindungen

Im Endeffekt also genau die Punkte, die sich bereits in den Empfehlungen des TechNet finden.

SPC 2014: KeyNote

Auch diesmal berichte ich wieder von der SharePoint Conference aus Las Vegas. Ein paar Berichte werden sicher erst nach und nach kommen, ich versuche das aber möglichst aktuell zu halten.

Die SharePoint Conference 2014 begann natürlich wie immer mit einer Keynote, die von Jared Spataro eröffnet wurde. Nach den üblichen Worten kam dann auch gleich Ex-Präsident Bill Clinton zu Wort, der vor allem über den Nutzen von Technologie beim Aufbau fairer Gesellschaftsstrukturen referierte mit Beispielen aus dem humanitären, öffentlichen und unternehmerischen Bereich.

Nach diesen Worten ging es dann mehr zur Technik. Jared Spataro wies darauf, dass die momentan aktuellen Themen wie Cloud, Social, Mobile und Big Data meist eher im privaten Bereich genutzt werden, als in den Unternehmen. Gerade Social Collaboration ist dort meist noch nicht richtig angekommen.

Auch mehrere offizielle Ankündigungen waren sehr interessant: es wird eine separate Lizenz für OneDrive for Business geben, die 25GB Speicher auf einer Office 365 Personal Site bereitstellen soll. Seit Service Pack 1 für SharePoint 2013 lässt sich diese auch direkt OnPremise einbinden.

Weitere Änderungen wir des bei Office 365 geben: bis zu 1TB Größe Site Collections und grenzenloser Tenant-Speicher wird Einzug halten, ein neues Videoportal und Office Graph zum Auffinden relevanter Informationen werden implementiert.

Aber auch OnPremise gibt es Neuigkeiten: 2015 wird es neue OnPremise-Releases von Office, SharePoint und Exchange geben.

Interessant war dann auch die Demo von Julia White zur künftigen Yammer-Integration in Office 365, Office Online und in das Design von Office 365.

Microsoft veröffentlicht Service Pack 1 für Office 2013, SharePoint 2013 und Exchange 2013

Wie im “Office Update Blog” nachzulesen ist, hat Microsoft das Service Pack 1 für die genannten Produkte veröffentlicht. Das Update für Office 2013 steht bereits über WSUS und Microsoft Update zur Verfügung.

Nach der Installation des Service Pack 1 auf SharePoint 2013 sind in der Zentraladministration direkt neue Optionen aufgetaucht, die sich sehr interessant anhören und die ich mir in der nächsten Zeit genauer anschauen werde:

Abfragen von großen Datenmengen in SharePoint

Da ich vor Kurzem wieder mal zu einem Kunden gerufen, der in seiner SharePoint-Umgebung sehr große Performance-Probleme hatte mit einer Eigenentwicklung, möchte ich die “Lessons Learned” an dieser Stelle nieder schreiben, da ich immer wieder erleben muss, dass Entwickler in Ihrer kleinen Entwicklungsumgebung vor sich hin “coden”, den späteren Produktiveinsatz und deren Datenmengen und –Strukturen aber völlig links liegen lassen.

Ausgangslage

Die produktive Umgebung läuft derzeit auf SharePoint 2007. Innerhalb einer WebApplication existieren derzeit 130.000 Site Collections verteilt auf 100 Datenbanken. Die gesamte Datenmenge umfasst etwa 1,4TB in den Datenbanken plus eine große Datenmenge in einem angeschlossenen Archivsystem.

Die Applikation selbst besteht aus einer Vielzahl von Komponenten, die ich hier nicht alle beschreiben kann. Wichtig sind immer die Startseite der Site Collection und die Startseiten der Sub-Sites. Hier werden in verschiedenen WebParts Übersichten über die Sub-Sites, über alle in der Site Collection vorhandenen Dokumente und bestimmte Dokumente aufgelistet.

Und genau hier versteckte sich auch das Problem. Große Site Collections können durchaus mehrere GB groß werden und ein paar Hundert Dokumente beinhalten. Und unter anderem auf solchen benötigt die Startseite zum Rendern meist mehrere Sekunden bis sogar zu einer Minute. Für die Akzeptanz des Gesamtsystems ist dies natürlich tödlich.

Für meine Tests und Verbesserungen hatte ich eine größere Site Collection mit 5GB Inhalt in 74 Sub-Sites und ein paar Hundert Dokumenten genommen.

Hinweis: Die folgenden Messungen sind nicht repräsentativ, da das Entwicklungssystem nicht sonderlich performant war. Allerdings spricht das Delta zur Verbesserung eine sehr deutliche Sprache und kann durchaus als Information für eigene Entwicklungen herangezogen werden.

Problem(e)

Viele hatten sich das System bereits angeschaut und die meisten haben es auf die Infrastruktur geschoben: “Der SQL Server ist dafür nicht ausgelegt”, “Sie brauchen mehr SharePoint Server” und “Das Storage darunter passt nicht” wurden geäußert.

Das Problem versteckte sich jedoch (wie meistens) ganz woanders: Es war die Art und Weise wie der Entwickler die benötigten Daten abgefragt hatte und wie die Gesamtstruktur der Sites aufgebaut war.

Beispiel 1: Iteratives Abfragen aller Web-Objekte

Ein WebPart ging durch alle Sub-Sites durch und suchte dort ein Element in einer speziellen versteckten Liste:

 

Durch die Instanziierung von allen SPWeb-Objekten bei jedem Aufruf ging jede Menge Zeit verloren und das WebPart benötigte bereits etwa 700-800ms. Dabei hatte der Entwickler bereits die Grundlagen für eine schnelle Abfrage gelegt, indem die Liste und das Element einen eigenen Content Type verwendeten. Dies ermöglichte eine sehr einfache Verbesserung durch die Verwendung eines SiteDataQuery:

Diese Änderung führte zu zwei Vorteilen:

  1. Die Ausführungszeit reduzierte sich auf 100ms
  2. Der Code ist sehr viel einfacher. Da GetSiteData() bereits eine DataTable produziert, musste diese für das anzeigende Grid nicht erst erzeugt werden.

Doch hier war noch nicht das Ende erreicht. Da die Informationen in den Listen sehr statisch sind, kann das Ergebnis ideal zwischengespeichert werden. Hierzu bietet SharePoint bereits den Object Cache an. Wenn bereits ein SiteDataQuery verwendet wird, ist die Nutzung des Object Cache sehr einfach realisierbar:

Hierdurch erhöhte sich die Ausführungszeit beim Erzeugen des Cache zwar auf etwa 130ms, jedoch konnten fortfolgende Requests innerhalb von 10ms bedient werden.

Beispiel 2: Iteratives Abfragen aller Web-Objekte

Auch das zweite Beispiel ist sehr ähnlich. Der erste Code-Teil iteriert durch die SPWeb-Objekte:

In der aufgerufenen Methode werden die Dokumente jedoch diesmal mittels eines CAML-Query abgefragt, allerdings auch wieder einzelne für jede Dokumentbibliothek:

Wie man erkennen kann, werden nach dem Erzeugen des Ergebnisses durch das CAML-Query wieder Elemente verworfen, die bestimmten Bedingungen nicht genügen. Idealerweise sollten diese in das CAML-Query aufgenommen werden, allerdings hat CAML auch gewissen Beschränkungen, die nicht alle Varianten von Bedingungen erlauben.

Folgender Code hat jedoch auch hier für eine Verbesserung der Laufzeit von 2.500ms auf etwa 10ms nach dem Cachen und 1.300ms zum Cachen gesorgt:

Beispiel 3: Verwendung von Contains statt separater Spalten

Die schwierigsten Performance-Probleme bei der Datenabfrage generell ergeben sich, wenn Strings nicht komplett vergleichbar sind, sondern nur Teilbereiche der Strings für Bedingungen herhalten müssen. Hier lässt sich auch nicht sehr viel optimieren, jede Art der Abfrage ist hier egal ob in SharePoint oder in anderen Systemen langsam. Um dies zu optimieren, müssend die Datenstrukturen verändert werden. Hinzu kommt in diesem Beispiel, dass die Kategorisierung von Dokumenten in SharePoint über Ordner vorgenommen wurde:

Das WebPart hat folgende Aufgabe: Es sucht Dokumente in der aktuellen Website, die in Ordner stehen, die im Namen “(sensible Daten)” stehen haben:

Hier wird rekursiv jeder Ordner auf oberster Ebene in jeder Dokumentbibliothek geprüft, ob der String “(sensible Daten)” im Titel vorkommt. Wenn er dazu noch Dokumente enthält wird er einer Liste hinzugefügt, die später für das WebPart gerendert wird. Dies führt zu einer Ausführungszeit von 500ms.

Auch hier habe ich versucht über ein CAML-Query das Ergebnis zu verbessern, allerdings ist die Verwendung der CAML-Methode “<Contains>” auch nicht sehr viel schneller. Folgender Code konnte eine Reduktion der Ausführungszeit von gerade einmal 150ms auf 350ms erreichen:

Man könnte hier auch wieder durch Verwendung des Object Cache das Ergebnis wahrscheinlich deutlich verbessern, sinnvoller wäre jedoch eine Anpassung der Datenstrukturen, z.B. durch Auslagerung des Flags “Sensible Daten” auf den Content Type des Dokuments, um diese mittels “<Eq>”-Methode per CAML zu finden. Doch diese Anpassung kann sehr viele Querverbindungen innerhalb der Gesamtlösung haben und ist damit mit sehr intensiven Tests verbunden. Zudem müssen alle Bestandsdaten modifiziert werden.

Fazit

In den vorigen Kapiteln habe ich ein paar Beispiele erläutert, wie viele Entwickler auf schnelle Art und Weise versuchen ein Problem zu lösen und den offensichtlichsten, aber damit nicht den schnellsten Weg gehen. Weitere Infos zu SPSiteDataQuery und CrossListQueryCache finden sich in einem interessanten Blog-Artikel von Vardhaman Deshpande: http://www.vrdmn.com/2012/11/querying-list-items-from-large-number.html.

In einem späteren Artikel werde ich versuchen auf Gründe für dieses Vorgehen eines Entwicklers und mögliche Lösungsansätze einzugehen.

Microsoft stellt InfoPath ein

Laut einem Beitrag im Office Team Blog wird es keine weitere Version von InfoPath nach Office 2013 mehr geben. Zwar wird InfoPath 2013 bis zum Jahr 2023 supported, allerdings nicht mehr weiter entwickelt.

InfoPath wird gern in von SharePoint zur einfachen Erzeugung von Formularen mit Logik und einfachen Oberflächen genutzt (um z.B. Prozesse und Workflows anzustoßen) oder auch zur Anpassung von Listenformularen.

Schon lange wurde über die Zukunft von InfoPath spekuliert, da in den letzten Versionen sehr wenige Neuerungen integriert wurden und viele Mängel nie richtig behoben wurden.

Eine Antwort zur zukünftigen einfachen Erstellung und Anpassung von Formularen in SharePoint gibt der Artikel jedoch nicht. Microsoft arbeitet offensichtlich an einer neuen Technologie, die im Laufe des Jahres vorgestellt werden soll. Auf der SharePoint Conference in Las Vegas im März soll es dazu einen Ausblick geben.

Was bleibt? Microsoft empfiehlt trotzdem derzeit weiter InfoPath zu nutzen. Wahrscheinlich wird die neue Technologie erst mit der nächsten Version von SharePoint Einzug halten. Mit K2 Forms oder Nintex Forms existieren jedenfalls im Dritthersteller-Markt auch potentielle Alternativen.

Änderungen der Forefront-Roadmap: FIM und UAG

Gestern gab es Neuigkeiten im Server & Cloud-Blog von Microsoft zum Forefront Identity Manager und Unified Access Gateway:

Im ersten Halbjahr soll eine neue Version des Identity Managers erscheinen, die vor allem Verbesserungen in den Bereichen Hybrid Environments mit Windows Azure, Benutzerverwaltung und Compliance bringen soll.

Das Forefront UAG jedoch wird Microsoft zum 01. Juli 2014 nicht mehr verkaufen. Die Supportzeiträume entsprechen denen vom TMG. Einige Features von Windows Server 2012 R2 stellen die Funktionalitäten hinsichtlich Application Publishing bereit (Web Application Proxy), womit der Haupteinsatzzweck von TMG und UAG rudimentär abgedeckt werden soll.

Den ganzen Beitrag finden Sie hier