SharePoint 2013 – Aufgabenliste verschickt keine E-Mails mehr?!

By Christian in Development, Infrastruktur, Neues, SharePoint 0 Comment

Seit SharePoint 2013 fehlt in den Einstellungen einer SharePoint Aufgabenliste die Option „Send e-mail when ownership is assigned? (Yes/No).“. Ich vermute einen Bug in der Oberfläche, der eventuell irgendwann wieder rausgepatchet wird. Nichts desto trotz schreibe ich einen kurze Artikel, wie man dieses Phänomen beheben kann.

Es gibt verschiedene Lösungsansätze, die ich hier kurz darstelle. Eins vorweg: Die Option 3 wäre immer meine erste Wahl!

1. Issue-List beinhaltet die Option noch
Also anstelle der Aufgabenliste das o.g. Template nutzen (vgl. Technet ).

2. Das „alte“ Template verwenden:
Über einen URL-Aufruf kann das „alte“ 2010er Template aufgerufen werden. (vgl. TechNet)
http://siteurl/_layouts/15/new.aspx?FeatureID={00BFEA71-A83E-497E-9BA0-7A5C597D0107}&ListTemplate=107

3. Powershell
Aus meiner Sicht die sauberste und beste der drei Alternativen. Benötigt natürlich Zugriff auf den Server, bzw. Zugriff auf einen Administrator. 😉

$web = Get-SPWeb "http://MeineWebseite"
$list = $web.Lists.TryGetList("Tasks")
$list.EnableAssignToEmail = $true
$list.Update()

Wie organisiere ich meine Dokumente in SharePoint? Ordner? Metadaten? – BEIDES!

By Christian in Neues, SharePoint 16 Comments

Hallo zusammen,

lange habe ich projektbedingt nichts mehr geschrieben – das will ich hiermit nachholen. 🙂

Ich widme mich heute einem Thema, das ich von der SharePoint Konferenz in Las Vegas mitgebracht habe und mir jetzt lange genug unter den Nägeln gebrannt hat. Inspiriert hat mich Scott Jamison mit dem Vortrag:

„Making SharePoint Collaboration Rock by Increasing Discoverability“

Achtung ab hier folgt viel Text! Wer das nicht lesen will, sondern sofort zur coolen Lösung springen möchte, sollte weiter nach unten zur Überschrift „Lösung“ scrollen! 🙂

Scott hat hier ein paar grundsätzliche Regeln vorgestellt, die bei dem Aufbau einer Collaboration-Plattform beachtet werden sollten. Es sind vor allem diese Grundsätze:

  • Verfolge einen klaren Leitfaden und eine klare Struktur
    • Verwende lieber weniger Metadaten als mehr!
    • Verwende wenige Schachtelungstiefen
  • Gebe den Anwendern einen einfachen und nachvollziehbaren Einstieg
    • Einfache Navigation
    • Schnelle Einstiegspunkte (nicht erst fünfmal Klicken)
  • Keep it simple, stupid! (KISS)
    • Verwende weniger Metadaten!!! (ja ich wiederhole mich!) 🙂
  • Verwende verschiedene Ansichten für bereitstellende und konsumierende Benutzer

Warum reite ich so auf dem Thema Metadaten rum?

Der Grund ist relativ einfach: Es wurde lange Zeit postuliert (ja auch von mir selbst), dass mit der Einführung von SharePoint bloß niemand mehr auf die Idee kommen soll Ordner zu verwenden. Ordner sind abgrundtief böse, von Natur aus schlecht und man verwendet diese einfach nicht mehr! Coole Jungs (und Mädchen) bauen eine möglichst komplexe Metadatenstruktur mit möglichst vielen (ineinander geschachtelten) Inhaltstypen und möglichst vielen Spalten pro Inhaltstyp. Jetzt steht man allerdings vor einem Problem: Die Anwender füllen die Felder nicht aus! Macht nichts, dafür gibt es ja Pflichtfelder und davon möglichst viele! 😉

Nun mal wieder etwas ernsthafter und vergleichen Metadaten und Ordner mal miteinander… 🙂

Metadaten:

Metadaten sind schon lange und Dokumentenmanagement- und Archivierungssystemen bekannt. Sie bieten eine einigermaßen einfache (wenn man es nicht übertreibt) Möglichkeit, Dokumente zu strukturieren und wiederzufinden. Metadaten sind außerdem für die SharePoint Suche immens wichtig.

Vorteile:

  • Man findet Dokumente einfacher
    • Durch intelligente Filteroptionen
    • Durch die SharePoint integrierte Suche (crawled und managed Properties, Relevanzen etc.)
  • Man legt die Daten wirklich strukturiert ab
  • Man überlegt sich eine Struktur und lässt es nicht wild wachsen

Nachteile:

  • Komplett anderes Vorgehen für die meisten Benutzer -> Umstellung in der täglichen Arbeitsweise
  • Gefahr das Dokumente „überstrukturiert“ werden d.h. das zu viele Spalten ausgefüllt werden müssen und der Anwender sich dadurch gegängelt fühlt
  • Gefahr das es viel zu komplex wird
  • Vorgehen ist wenig intuitiv für die Benutzer
  • OneDrive / Explorer stellen die Metadaten nicht dar
  • Keine native Verschlagwortung mehrerer Dokumente auf einmal (Jedes Dokument muss ohne Drittanbieter-Tools separat angefasst werden)

Ordner:

Auf der Gegenseite steht die Verwendung von Ordnerstrukturen. Dies kennen und verwenden die Anwender bereits seit Jahrzehnten. Hier fühlen sie sich einfach heimisch.

Vorteile:

  • Dokumente können schnell bereitgestellt werden (kein langes Ausfüllen der Metainformationen)
  • Verwendung durch die Benutzer bekannt => Lösung wird schneller adaptiert und ist intuitiv
  • Datei-Explorer Integration!!!
  • Auch in OndDrive synchronisierten Bibliotheken sichtbar
  • Zusätzliche Rechtevergabeoption

Nachteile:

  • Das Suchen wird schwierig
  • Häufig entsteht Wildwuchs
  • Die SharePoint Suche wird nicht voll ausgenutzt

Lösung:

Gibt es jetzt eine Möglichkeit beide Welten irgendwie zu vereinen? Antwort: JA – durch die „Column Default value settings“! Diese Option ist in den Einstellungen der Dokumentbibliotheken verfügbar. Sie führt dazu, dass Metadaten einem Dokument automatisch hinzugefügt werden, sobald diese in einem bestimmten Ordner hinterlegt werden.

Einfaches Beispielszenario:

Ich habe das Szenario für den Beitrag bewusst einfach gehalten, damit es nachvollziehbar bleibt.

  • Verwaltung von Kundendokumenten
  • Zwei verschiedene Metainformationen
    • Kundenname
    • Dokumentart: Vertrag, Angebot, Kostenvoranschlag
  • Verwendung von Ordnern und Metadaten

Vorgehen:

1. Erstellen einer Dokumentbibliothek „Kunden“ und Anlegen der beiden obigen Spalten als „Auswahl“-Feld

Spaltenübersicht:

.

 Spalte „Kunde“ Spalte „Kategorie“050614_1635_Wieorganisi3.png

2. Anlegen der Ordnerstruktur

– Ebene 1: Kundenname
– Ebene 2: Dokumentenkategorie (Angebot, Vertrag, Kostenvoranschlag)

1. Ebene: 2. Ebene:

3. Setzen der Column default value settings:

Auf der linken Seite wird die Ordnerstruktur als „Tree-View“ dargestellt. Hier klickt (1) man jetzt auf den gewünschten Ordner (z.B. BMW). Danach klickt (2) man auf die gewünschte Metainformation / Spalte (in diesem Fall „Kunde“)

Einstellung

Es öffnet sich ein neues Fenster, in dem der gewünschte Standardwert des Ordners eingetragen werden kann.

Ein grünes Rädchen am Ordner verrät, dass hier Werte gepflegt wurden.

Wichtig: Die Werte werden an die untergeordneten Objekte standardmäßig vererbt. Man muss diese als nicht doppelt pflegen!

4. Testen:

Sobald alle Werte den Ordnern zugewiesen wurden, kann auch schon getestet werden. Ich öffne für diesen Fall den Ordner „BMW“ -> „Vertrag“ und ziehe per Drag and Drop ein Dokument in den Ordner und die Metadaten werden direkt übernommen:

Das Ganze funktioniert auch über den „File-Explorer“ und mit mehreren Dokumenten auf einmal:

Upload1

Im Browser werden die Dateien auch direkt mit den Metainformationen versehen:

Die automatische Verschlagwortung funktioniert auch über die Explorer-View aus dem Dateisystem oder im OneDrive. Dies macht es noch einfacher viele Dokumente schnell bereit zu stellen.

5. Verbesserung der Suche für die Anwender:

Über dieses System können Dokumente sehr schnell verschlagwortet werden ohne das sich der Anwender großartig darüber den Kopf zerbrechen muss. Wenn nun aber jemand Dokumente suchen will, hat man erstmal wieder die Ordnerstruktur, durch die man durchklicken muss. Um dies zu verbessern, sollte jetzt eine eigene Ansicht gebaut werden, die die Ordnerstrukturen ignoriert.

Neue View erstellen und die gewünschten Felder auswählen:

Danach kann man in der Rubrik „Ordner“ auswählen, ob die Ordnerstruktur für die View beibehalten oder eine flache Liste der Dokumente angezeigt werden soll:

Danach kann man in der Ansicht wie gewohnt filtern:

Filter

Zusätzlich kann jetzt natürlich noch die SharePoint Suche über die „crawled“ und „managed“ Properties angepasst werden. Das würde aber hier ein wenig zu weit führen. 😉

Fazit:

Eine Interessante Option um die Welten „Ordner“ und „Metadaten“ miteinander zu kombinieren. Man muss aber aufpassen, dass die Regeln nicht zu komplex und die Verschachtelung zu tief wird. Ansonsten ist das Ganze später nicht mehr wirklich wartbar.

Autovervollständigung beim PeoplePicker

By Henning Eiben in SharePoint 1 Comment

Wenn man in einer SharePoint-Liste ein Feld vom Typ “Personenauswahl” hinzufügt, dann bekommt man automatisch in den Formularen einen sogenannten PeoplePicker. Das ist ein Feld, in dem man einen Namen, ein Benutzerkonto oder eine eMail-Adresse eingeben kann. Wird der Benutzer erkannt, wird der Name unterstrichen dargestellt, ansonsten wird er mit einer roten Schlangenlinie versehen.

people_picker_01

Über das Adressbuch kann ich einen Suchdialog öffnen um nach Personen zu suchen, wenn ich z.B. nur einen Teil des Namens kenne.

people_picker_02

Das ist aber irgendwie lästig auf diese Art und Weise zu suchen, weil man immer diesen Dialog öffnen muss, dann auf Suchen klicken muss und den gefundenen Treffer auch noch übernehmen muss. Besser wäre es also, wenn man in dem eigentlichen Feld direkt einen Teil des Namens eingeben könnte und man würde eine kleine Liste mit Vorschlägen bekommen.

people_picker_03

Praktischerweise gibt es da auch schon was … mit JavaScript! Alexander Bautz hat vor ein paar Jahren auf seinem Blog beschrieben, wie man so einen People-Picker um Autovervollständigung ergänzen kann.

Ich will die notwendigen Schritte hier nicht wiederholen, stattdessen sei auf den Blogpost verwiesen. Die Einbindung ist eigentlich ganz einfach, erfordert lediglich einen Kniff – die GUID der Benutzerliste.

Um an die GUID zu kommen ruft man einfach die Benutzerliste auf. Jede Websitesammlung hat eine solche Liste, die man über /path-to-my-sitecollection/_catalogs/users erreichen kann. Anschließend die Quellcode-Ansicht für die Seite öffnen und nach ctx.ListName suchen. Voila, schon hat man die GUID.

Kleiner Hinweis noch: die Autovervollständigung kann nur Benutzer vorschlagen, die sich auch schon mal auf der Site angemeldet hatten, denn nur diese Benutzer sind in der Benutzerliste vorhanden.

Wie groß ist mein SharePoint?

By Henning Eiben in SharePoint 0 Comment

Jetzt hatte ich doch gerade die Frage: wie groß ist eigentlich meine ContentDatenbank meiner aktuellen Site-Collection? Und weil ich Herausforderungen mag: SharePoint 2007 bzw. Windows Services 3.0.

Natürlich gibt es nur einen Weg um dies herauszufinden:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = New-Object Microsoft.SharePoint.SPSite("http://portal.acme.local")
$diskMethod = [Microsoft.Sharepoint.Administration.SPContentDatabase].getMethod("get_DiskSizeRequired")
$diskMethod.Invoke($site.ContentDatabase, "instance,public", $null, $null, $null)

Das Ergebnis zeigt die Größe der Datenbank in Bytes an.

Geht doch!

Doppelte Treffer bei der Personensuche

By Henning Eiben in SharePoint 0 Comment

Die Tage hatte ich die Anfrage eines Kunden:

auf unserer Startseite werden alle Ansprechpartner doppelt angezeigt.

Hintergrund ist, dass für die Anzeige der Ansprechpartner ein Such-WebPart verwendet wird, welches eine Personensuche nach einer bestimmten Abteilung anzeigt.

Wie auch immer – auch bei der “normalen” Suche nach einem Mitarbeiter wird dieser doppelt in der Suche nagezeigt. Komisch.

Die Lösung ist dann recht einfach – aber dennoch interessant. In den Inhaltsquellen waren zwei Einträge mit dem Protokoll SPS3:// vorhanden. Daraufhin wurden alle Personen doppelt in den Index gecrawlt.

search_sps3

Was ich dabei interessant finde ist die Tatsache, dass SharePoint bei der Anzeige der Ergebnisse Duplikate nicht aussortiert – ich hätte auch erwartet, dass er Duplikate vielleicht gar nicht in den Index aufnimmt.

Wie auch immer – den doppelten Eintrag entfernt und einen Full-Crawl später war dann alles wieder wie gehabt.

Es geht nicht ohne: PowerShell und SharePoint

By Henning Eiben in SharePoint 0 Comment

Es geht doch nichts über Rituale. Ich bin also gerade auf einem SharePoint-Server als Farm-Admin eingeloggt und wollte ein wenig powershellen. Und da kommt die Meldung:

Auf die lokale Farm kann nicht zugegriffen werden. Cmdlets mit `FeatureDependencyId`sind nicht registriet.

Wer kennt die Meldung nicht. Und warum ist die da: Sicherheit. Nur Farm-Admin reicht halt für die PowerShell nicht (Ach so: natürlich habe ich meine PowerShell schon mit erhöhten Rechten gestartet, das ist doch klar).

Was ist nun also das Problem? Der Benutzer ist zwar Farm-Admin, kann aber von der Shell nicht direkt auf die Datenbanken von SharePoint zugreifen. Somit kann ich die meisten PowerShell Befehle (für SharePoint) nicht durchführen. Wenn ich nun also doch mal ein Get-SPWebApplication “foo” mache, dann bekomme ich die Meldung

Auf die lokale Farm kann nicht zugegriffen werden. Vergewissern Sie sich,. dass die lokale Farm ordnungsgemäß konfiguriert sowie aktuell verfügbar ist und Sie über ausreichende Berechtigungen verfügen, um auf die Datenbank zugreifen zu können, bevor Sie es erneut versuchen.

Aha – das steht’s ja schon. Ich kann nicht auf die Datenbank zugreifen. Um das Zu ändern gibt es den Befehl Add-SPShellAdmin. Nur dumm, dass ich den als jemand ausführen muss, der über entsprechende Berechtigungen verfügt (also der schon Shell-Admin ist).

Na gut, dann muss dafür mal eben kurz der spFarm herhalten. Also eben eine CMD als spFarm gestartet mit

runas /user:spFarm cmd

und dann eine PowerShell starten. Hierbei muss diese aber elevated gestartet werden, und dass vom Prompt aus. Das geht eigentlich auch ganz einfach

@powershell Start-Process -Verb "runas" powershell

So, nun habe ich also eine PowerShell als spFarm mit erhöhten Rechten. Der Rest ist einfach

Add-PSSnapin Microsoft.SharePoint.PowerShell
Add-SPShellAdmin busitec\eiben

Wenn ich nun wieder hingehe und eine SharePoint Verwaltungsshell (mit erhöhten Rechten) starte, dann kann ich auch per PowerShell auf die Farm zugreifen.

Voila!

Ein paar Fragen an das Active Directory

By Henning Eiben in Infrastruktur, SharePoint 0 Comment

Beim Betrieb einer SharePoint-Farm ist man auf die korrekte Pflege von Accounts im Active Directory angewiesen. Gerade im Zusammenhang mit Kerberos ist es wichtig, dass alle Einstellungen im Active Directory richtig eingetragen werden, damit die Authentifizierung auch ohne Probleme funktioniert.

Als SharePoint-Farm Administrator hat man dazu allerdings nicht immer ohne weiteres Zugriff auf das Active Directory, zumindest nicht auf die Management-Tools. Nun stellt sich also die Frage, wie kann ich feststellen, welche Service-Principles alle für einen Account im Active Directory registriert wurden. Wenn ich Zugriff auf einen Domain-Controller hätte, dann würde ich ganz einfach SETSPN verwenden.

C:\>SETSPN spIntranetWA
Registered ServicePrincipalNames for CN=spIntranetWA,OU=Dienstkonten,OU=HeadQuarter,DC=acme,DC=local:
    HTTP/sp01.acme.local
    HTTP/intranet.acme.local

Aber SETSPN kann ich nur direkt auf einem Domain Controller ausführen, da komme ich als SharePoint Farm-Admin also nicht drauf. Was nun?

Wie bei allen Administrativen gibt es eine Ultimative Antwort: PowerShell!

Die Lösung ist so einfach, ich traue mich die ja schon kaum zu posten. Mit folgendem Befehl kann ich alle Einträge im Active Directory suchen, deren Account-Name “spIntranetWA” ist:

C:\> ([adsisearcher]"samaccountname=spIntranetWA").FindAll()

Path                                                        Properties
----                                                        ----------
LDAP://CN=spIntranetWA,OU=Dienstkonten,OU=HeadQuarter,... {logoncount, codepage, objectcategory, usnchanged...}

Damit habe ich schon mal ein paar Informationen.

Das funktioniert natürlich von jedem Arbeitsplatz mit PowerShell. Im Gegensatz zu den Active-Directory cmdlets verwende ich hier den ADSISearcher (dabei handelt es sich um ein Alias für die DirectorySearcher-Klasse aus dem .Net Framework). Das ist eine der genialen Dinge der PowerShell – ich kann mal eben so was aus dem .Net Framework verwenden. Um nun Objekte im Active-Directory zu suchen kann man dem ADSISearcher LDAP-Abfragen übergeben.

Insbesondere die Properties sind hierbei interessant. Die kann man sich auch etwas genauer ansehen.

C:\> $accounts = ([adsisearcher]"samaccountname=spIntranetWA").FindAll()
C:\> $accounts.properties

Name                           Value
----                           -----
logoncount                     {323}
codepage                       {0}
objectcategory                 {CN=Person,CN=Schema,CN=Configuration,DC=acme,DC=local}
usnchanged                     {15699245}
instancetype                   {4}
name                           {spIntranetWA}
pwdlastset                     {128843629222870406}
serviceprincipalname           {HTTP/sp01.acme.local, HTTP/intranet.acme.local}
objectclass                    {top, person, organizationalPerson, user}
samaccounttype                 {805306368}
lastlogontimestamp             {130265658248173942}
usncreated                     {19523}
dscorepropagationdata          {21.06.2013 13:56:40, 21.06.2013 12:28:23, 20.07.2012 09:54:16, 01.01.1601 18:16:33}
whencreated                    {16.04.2009 13:42:02}
adspath                        {LDAP://CN=spIntranetWA,OU=Dienstkonten,OU=HeadQuarter,DC=acme,DC=local}
useraccountcontrol             {590336}
cn                             {spIntranetWA}
countrycode                    {0}
primarygroupid                 {513}
whenchanged                    {18.10.2013 10:30:24}
lastlogon                      {130270479005600192}
distinguishedname              {CN=spIntranetWA,OU=Dienstkonten,OU=HeadQuarter,DC=acme,DC=local}
samaccountname                 {spIntranetWA}
objectsid                      {1 5 0 0 0 0 0 5 21 0 0 0 130 139 166 40 17 195 95 115 138 167 50 63 245 22 0 0}
displayname                    {spIntranetWA}
objectguid                     {217 8 220 57 70 168 118 76 178 20 180 160 198 219 146 67}
accountexpires                 {9223372036854775807}
userprincipalname              {spIntranetWA@acme.local}

Hier kann man auch den ServicePrincipleName ablesen. Der Rest ist dann nur noch ein wenig  PowerShell gefummel, um das ganze dann auch tabellarisch angezeigt zu bekommen.

C:\> ([adsisearcher]"samaccountname=sp*").FindAll()|select @{name='cn'; expression = {$_.properties['cn']}}, @{name="spn"; expression={$_.properties["ServicePrincipalName"]}}

cn                      spn
--                      ---
spCrawl
spDBAccount
spExtranetWA
spFarm
spInternetWA
spIntranetWA            {HTTP/sp01.acme.local, HTTP/intranet.acme.local}
spMySites
spSearch
spSPService

Lokalisierung in Office365

By Henning Eiben in SharePoint 3 Comments

Und mal wieder eine (Erfolgs)Geschichte aus Office365 … also ich habe da so eine Mysite unter busitec-my.sharepoint.com. Die Mysite wurde ursprünglich in Englisch angelegt, und anschließend habe ich die Sprache auf „Deutsch“ umgestellt.

site_setting_locale

Wenn ich nun einen Blog anlege, dann ist der zunächst auf Englisch; kein Problem. Also Sprache auf Deutsch umstellen. Sieht ja alles Super aus – alles läuft; oder etwa nicht? Wenn ich nun in “Beiträge verwalten” gehe und mir alle Beiträge der Liste anzeigen lasse und dann einen einzelnen Beitrag anklicke …

post_error

Wow! Was ist denn das? Eine Fehlermeldung, und das bei O365? Wie kann denn das … und viel Interessanter ist ja noch, wenn ich den Beitrag direkt von der Startseite aus aufrufe, dann geht’s?!

OK – die Erklärung ist dann doch ganz schnell gefunden. Wenn ich den Beitrag von der Startseite aus aufrufe, dann sieht die URL wie folgt aus:

https://busitec-my.sharepoint.com/personal/eiben_busitec_de/Blog/Lists/Posts/Post.aspx?ID=1

Wenn ich aber über die Liste der Beiträge gehe und dann auf den Titel klicke wird diese URL aufgerufen:

https://busitec-my.sharepoint.com/personal/eiben_busitec_de/Blog/_layouts/15/listform.aspx?PageType=4&ListId=%7B36A2AAFB%2D5143%2D403F%2DA325%2DA7610CDE8EA6%7D&ID=1&ContentTypeID=0x01100007A0E26C347C5F4899398346B0DAF58B

…die dann einen Redirect auslöst auf:

https://busitec-my.sharepoint.com/personal/eiben_busitec_de/Blog/Lists/Beitraege/Post.aspx?List=36a2aafb%2D5143%2D403f%2Da325%2Da7610cde8ea6&ID=1&Source=https%3A%2F%2Fbusitec%2Dmy%2Esharepoint%2Ecom%2Fpersonal%2Feiben%5Fbusitec%5Fde%2FBlog%2FLists%2FPosts%2FAllPosts%2Easpx&ContentTypeId=0x01100007A0E26C347C5F4899398346B0DAF58B

Hier wird also die URL lokalisiert Smile ist zwar nett von SharePoint, dass er so viel wie möglich lokalisieren will – aber bitte doch nicht die URL. Denn eine Liste Beitraege gibt es nicht. Die würde es nur dann geben, wenn beim Anlegen der Site auch “Deutsch” ausgewählt gewesen wäre. Dann würde SharePoint die Namen der Listen an die Sprache anpassen.

Interessant ist IMHO, dass das listform.aspx (welches für den Redirect zuständig ist) nicht erkennt wie die Liste mit der ID 36A2AAFB-5143-403F-A325-A7610CDE8EA6 wirklich heißt.

Nachdem ich ja nun schon vor 3 Wochen einen Fehler in Nintex beim Auflösen von Gruppennamen und letzte und diese Woche einen Fehler in ShareGate beim kopieren von HTML-Inhalten gefunden habe, werde ich diesen Fehler auch mal versuchen an Microsoft zu melden – immer muss man alles selber machen.

Satya Nadella – Microsoft CEO

By Andrej Doms in Neues, SharePoint 0 Comment

Es hat einige Monate gedauert, aber nun wissen wir bescheid. Satya Nadella ist seit gestern der neue CEO von Microsoft und damit der Nachfolger von Bill Gates und Steve Ballmer. Die wichtigsten offiziellen Infos dazu findet man in den Microsoft Company News und im TechNet Blog.

Satya Nadella

Besonder hinweisen möchte ich auf 3 Videos:

Partner Webcast:

 

Ein kurzes Interview mit Satya Nadella in den Company News:

 

Satya Nadella spricht zu Microsoft Angestellten im Studio B:

In ein paar Tagen lasse ich mich vielleicht auch zu einem Kommentar hierzu hinreissen… 🙂 …dann sicher per Podcast.

Wie geht´s weiter mit InfoPath?

By Andrej Doms in Infrastruktur, Neues, SharePoint 0 Comment

Das Gerücht geht ja schon länger, dass wir uns in der nächsten Iteration des SharePoints leider von InfoPath verabschieden müssen. Das Feature wird „Deprecated“ und nicht mehr weiterentwickelt, bzw. nicht mehr Teil eines nächsten Releases sein.

Im  Office Blog gab es letzte Woche ein Post vom Office Team, das zumindest ein bißchen mehr Klarheit gebracht hat. Ein bißchen… 🙂

Wird uns so nicht mehr lange erhalten sein...

Wird uns so nicht mehr lange erhalten sein…

Die wichtigsten Aussagen sind:

  • Im Rahmen der SPC 2014 wird es eine Session geben, die einen Ausblick auf die Roadmap bezüglich Forms in SharePoint geben soll.
  • Wie lange dürfen wir es denn noch benutzen?
    How long will InfoPath be supported?

    • The InfoPath 2013 client will be supported through April 2023.
    • InfoPath Forms Services for SharePoint Server 2013 will be supported until April 2023.
    • InfoPath Forms Services in Office 365 will be supported until further notice.

    Das sagt nichts dazu aus, ob eine Lösung wenigstens die nächste Version noch ohne Migration überlebt. Klarer wird da schon folgendes Statement:

  • Will there be a migration tool or process for the next generation of forms technology?
    We’ll provide more details on migration scenarios and guidance in Q4 of CY 2014.
    Alles klar, es scheint darauf hinauszulaufen, dass ohne Migration nix mehr geht.
  • Zu Office 365 fällt folgendes Statement:
    The InfoPath Forms Services technology within Office 365 will be maintained and it will function until further notice.Hmmmm…..

Fazit: Es bleibt spannend. Microsoft wird uns möglicherweise 2015 etwas neues liefern. Im O365 wird es weiteren Support geben, allerdings keine Aussage, wie lange und in welcher Form. Der Client stirbt auf jeden Fall. Sind wir jetzt schlauer als vorher? Nein…. 🙁