Microsoft Teams wird für Unternehmen immer wichtiger. Sei es zur Verwaltung und Kollaboration innerhalb von Abteilungen oder aber zum Abwickeln von Projekten mit internen sowie externen Benutzern.
Nicht alle Einstellungen lassen sich allerdings über das Benutzerinterface steuern oder sind mit sehr viel Zeitaufwand verbunden. Im folgenden Beitrag möchte ich zeigen, wie sich bestehende Exchange Ressourcen auch für Teams Meetings nutzen lassen.
Mit Single Part App Pages hat man die Möglichkeit SharePoint Framework Webparts oder Teams Apps auf einer Seite mit gesperrtem Layout anzuzeigen. (aktuell ist diese Funktion nur in SharePoint-Online verfügbar)
(mehr …)Im Zuge eines Kundenprojektes auf Basis SharePoint 2016 hatten wir die Anforderung die Sprachumschaltung für die Endbenutzer zu vereinfachen. Idee war, im Header die Flaggen von Österreich und Großbritannien anzeigen zu lassen und die Sprache durch einen Klick auf die jeweilige Flagge auf Deutsch oder Englisch umzuschalten.
Wie ja mittlerweile so gut wie alle wissen wurde InfoPath von Microsoft abgekündigt. Und auch wenn der Support noch für einige Jahre seitens Microsoft sichergestellt ist, machen sich unsere Kunden Gedanken zu alternativen Formularlösungen für SharePoint.
Eine Möglichkeit InfoPath Formulare und deren Logik abzulösen ist z.B. Nintex Forms. Nachdem man das Nintex Formular fertig erstellt und mit allen Funktionen des bisherigen InfoPath Formulars versehen hat, reichen ein paar Klicks um das neue Formular zu exportieren und auf eine Liste zu übertragen. Das geht über die GUI sehr schnell und komfortabel.
Was aber wenn man es mit einem Projektportal mit hunderten Projekten zu tun hat? Wobei jedes Projekt eine Site darstellt in der eine Liste mit einem InfoPath Formular existiert? Sicher, man kann die hunderten Formulare manuell umstellen, was aber sicher ein paar Tage dauern wird und fehleranfällig ist.
Eleganter ist es das Austauschen mittels PowerShell zu erledigen. Der erste Schritt dazu ist das alte InfoPath Formular zu deaktivieren und zu löschen. Ansonsten kann man gerne ein anderes Formular zuweisen, aber SharePoint wird noch immer versuchen InfoPath zu öffnen.
Wir haben dazu ein Script erstellt das grob beschrieben folgende Schritte erledigt:
Und hier das fertige Script:
Danach kann man mit der automatisierten Verteilung der neuen Formulare (z.B. Nintex) starten. Hoffe dieser kurze PowerShell Ausflug konnte weiterhelfen. Wer Fragen zu dem Thema hat kann uns natürlich gerne kontaktieren 🙂 .
Mit SharePoint 2016 bringt Microsoft so manche Neuerungen in die Zentraladministration des SharePoint. Eine davon ist die sogenannte „Fast Site Collection“. Mit Hilfe dieser Funktion soll die Dauer der Erstellung einer neuen Site Collection von einer gefühlten halben Ewigkeit auf ca. 2-3 Sekunden reduziert werden!
Um eine neue Site Collection mit Hilfe dieses Features anlegen zu können sind vorbereitende Schritte notwendig.
Zu aller erst wird ein Grundgerüst benötigt um zukünftige Site Collections darauf aufbauend, erstellen zu können. Hierfür kann ein bereits vorhandenes Site Template verwendet werden, oder ein eigenes Template generiert werden. Möchte man ein selbst generiertes Site Template verwenden, muss dies im Vorhinein noch in ein Farm Template konvertiert werden um damit Site Collections erstellen zu können. Dies bedeutet jedoch auch, dass neue Site Collections nur dann mit dem neuen Fast Site Collection Feature angelegt werden, wenn bei der Anlage das Template ausgewählt wurde, bei dem auch der „Site Master“ aktiviert wurde.
Microsoft hat ja Ende August die SharePoint 2016 IT Preview veröffentlicht und somit die Möglichkeit gegeben, einen ersten Blick auf die neue SharePoint Version zu werfen.
Das wollte ich mir natürlich nicht entgehen lassen und habe mir daher die Preview ein wenig genauer angesehen. Abgesehen von den Informationen der Microsoft Ignite und Bill Baers Blog sind die Informationen zur neuen SharePoint Release ja noch recht spärlich gesät.
Im heutigen Blog Post möchte ich mich vor allem auf das “neue” Rollenmodell bei SharePoint 2016 konzentrieren. Dieses MinRole genannte Konzept besagt, dass innerhalb einer Farm benötigte Service Instanzen von SharePoint selbstständig konfiguriert und überwacht werden.
Wir hatten neulich bei einem Kunden dass Problem, dass sich, beim Erstellen einer Synchronisation Connection im User Profile Service, bestimmte Organisational Units (OUs) aus einem Active Directory Forrest nicht aufklappen ließen. Die Sub-Domains des Forrests konnten ohne Probleme aufgelöst werden, aber leider keine OUs aus der Root Domain.
Zunächst große Verwirrung… 
warum funktioniert das bei einigen OUs aber nicht bei allen ? Der einzige Hinweis auf einen Fehler im ULS Log war ein Session Timeout von SharePoint. Also zunächst einmal die Session Timeouts für die Synchronisation verändert (siehe Spencer Harbar)
Doch auch das hatte nicht den gewünschten Effekt. 
In SharePoint 2013 gibt es die Möglichkeit, echte Hashtags zu nutzen, in der Form #tag. Als SharePoint Entwickler ist man natürlich daran interessiert, Hashtags programmatisch zu nutzen. Dafür gibt es natürlich auch eine API. Eine umfassende Dokumentation dazu gibt es in der MSDN (https://msdn.microsoft.com/EN-US/library/office/jj163864.aspx). Es werden selbstverständlich sämtliche APIs vom .NET client object model, Server object model bis hin zum JavaScript object model sowie REST services unterstützt. In diesem Beitrag wird das „Server object model“ als „Starting-Point“ gezeigt.
Will man also ein Hashtag programmatisch hinzufügen, ist die Klasse SocialTagManager notwendig. Sie befindet sich im Assembly Microsoft.Office.Server.UserProfiles (Namespace, Microsoft.Office.Server.SocialData). Dies ist noch keine wesentliche Neuerung, da diese bereits in SharePoint 2010 zur Verfügung stand. Der Unterschied ist jedoch erkennbar, wenn man das Term Store Management Tool aufruft. Dort werden Hashtags im System-Zweig des Taxonomy Term Stores abgelegt.
Wer schon mal versucht hat, die seit SharePoint 2013 neue Assembly Microsoft.SharePoint.Client.Taxonomy zu verwenden um mittels CSOM auf das Managed Meta Data Service zuzugreifen, hat vielleicht schon mal folgende Fehlermeldung gesehen.
Cannot invoke method or retrieve property from null object.
Object returned by the following call stack is null.
„GetDefaultSiteCollectionTermStore
Microsoft.SharePoint.Taxonomy.TaxonomySession.GetTaxonomySession“
Das Code-Fragment, das diese Fehlermeldung verursacht sieht beispielsweise so aus.
Anmerkung: Dieses Beispiel legt einen Termset “Intrigen der Macht”, mit den Titeln von drei Büchern an, in der Gruppe “Books”.
In der Vergangenheit war es nicht immer einfach die von Visual Studio mitgebrachte Möglichkeit für Unit Tests in Verbindung mit SharePoint zu nutzen. In den aktuellen Versionen (SharePoint 2013 und Visual Studio 2013) ist dies einfacher geworden und sollte auch anregen daran zu denken, wenn man SharePoint Apps entwickelt. Gerade wenn man an Auto-hosted Apps denkt, bei denen die Businesslogik außerhalb des SharePoints, in beispielsweise einem Azure Service gehostet wird, sollte man Unit Tests unbedingt nutzen.
Aber nicht nur für SharePoint Apps sind sie eine wichtige Möglichkeit Qualität in eine Lösung zu bringen, sondern auch für die traditionellen (Full-trusted) Lösungen, wie man sie hinlänglich kennt. Unit Tests im Zusammenspiel mit Full-trusted Solutions waren eben mitunter recht schwierig umzusetzen.
Beispielsweise kann man damit einen Unit Test schreiben, um Eventreceiver einer Liste zu testen. Legt man ein SharePoint Projekt an, dann ist es relativ leicht auch ein Unit Test Projekt zu erstellen, um das Ausführen von Eventreceivern zu testen. Geht man von einem Eventreceiver aus, der z.B. ein Datumsfeld setzt, wenn ein neues Item angelegt wird, so braucht man anschließend nur einen Unit Test, der genau diesen Fall überprüft, erstellen.
