Microsoft 365 Sharing und OTP Auth

Letztes Jahr hat Microsoft hinsichtlich Sharing in OneDrive for Business und SharePoint Online eine große Änderung vorgenommen. Wenn anonyme Links nicht zugelassen waren, musste der Externe entweder über einen Entra ID-Account oder Microsoft Account verfügen.

Seit letztem Jahr wurde diese Funktion zur Anlage eines Gastaccounts seitens Microsoft verändert. Bei Einladung von Externen zu Teams und SharePoint Sites bleibt alles wie gehabt. Lediglich beim Teilen von Dateien und Ordnern in OfB und SPO ergibt sich ein anderes Bild:

Der Empfänger erhält eine E-Mail mit dem Link auf die Datei. Dort muss er dann seine E-Mail-Adresse erneut eingeben und erhält ein OTP zur einmaligen Authentifizierung und kann danach auf die Datei zugreifen.

Die Unterschiede der drei Varianten beleuchtet folgender Artikel auch mit Screenshots sehr gut: SharePoint and Microsoft 365 External Sharing with Non-Microsoft Accounts | SharePoint Maven

Problem ist nun, dass das Verhalten aus meiner Sicht nicht konsistent ist. Damit werden MFA-Anforderungen und auch das Abnicken von Nutzungsbedingungen (die teilweise von Unternehmen gefordert werden) umgangen.

Um das alte Verhalten auch für Datei- und Ordnerlinks zu implementieren, bringt es leider auch nichts, den IdP “Email one-time passcode” zu deaktivieren, am Verhalten ändert sich nichts:

Stattdessen muss die AAD-B2B-Integration aktiviert werden. Dies erfolgt mit einem einfachen PowerShell-Befehl für den SharePoint Online-Tenant, der in folgendem Artikel beschrieben ist: : https://learn.microsoft.com/en-us/sharepoint/sharepoint-azureb2b-integration#enabling-the-integration

Damit erfordern die Links zukünftig wieder, dass der Externe einen Gast-Account anlegen und sich mit MSA oder EntraID authentifizieren muss. Und die Terms of Use müssen auch wieder abgenickt werden.

Viva Connections – Intranet in Teams Client einbetten

Mit Viva Connections kann seit Mai 2021 eine neue App per Skript erstellt werden, die sich in Teams integrieren lässt. Damit lässt sich ein auf SharePoint Online basierendes Intranet als App in Teams integrieren, damit die Mitarbeiter den Client nicht verlassen müssen, um das Intranet einzusehen:

Intranet in Teams – Quelle: Microsoft

Vor Mai 2021 gab es hierzu auch eine Erläuterung von Microsoft, wie eine solche App mit dem Teams App Studio entwickelt werden kann (Spoiler: Auch dafür waren keine Entwickler-Kenntnisse notwendig 😉). Jetzt lässt sich das alles per PowerShell erstellen.

Basis für diesen Artikel ist folgender Artikel von Microsoft: Viva Connections für Microsoft Teams-Desktop hinzufügen – SharePoint in Microsoft 365 | Microsoft Docs

Voraussetzungen

Wie im Artikel ausgeführt, gibt es verschiedene Empfehlungen zu vorbereitenden Maßnahmen:

Globale Navigation aktivieren

Mit dem hier verfügbaren Artikel aktivieren Sie die „Globale Navigation“. Das heißt, sie definieren die SharePoint Site, die Sie als Hauptnavigations-Quelle (idealerweise als Hub Site definiert und mit einem entsprechenden Menü ausgestattet) definieren möchten:

Globale Navigation – Quelle: Microsoft

Definition der SharePoint Homepage

Die SharePoint-Homepage definiert das Hauptziel für das Intranet in Ihrem Tenant. Es wird z.B. innerhalb der SharePoint Mobile App als Homepage angezeigt und verwendet. Das Ziel der Homepage muss eine Kommunikationswebsite aus Ihrem SharePoint Online Tenant sein. Hinweise und die Anleitung zur Konfiguration per PowerShell, finden Sie hier: Festlegen einer Website als Startseite – SharePoint in Microsoft 365 | Microsoft Docs

Viva Connections App erstellen

Das Erstellen der App ist sehr einfach. Unter Download Viva Connections for Teams desktop from Official Microsoft Download Center finden Sie das PowerShell-Skript, das Sie einfach lokal entpacken und mit PowerShell ausführen. Sie müssen hierzu SharePoint-Administrator und Besitzer der Site sein, die Sie dort als Intranet-URL angeben.

Folgende Details müssen Sie im Script angeben:

  • Name: Der Name Ihres Viva Connections-Desktop-Paketes, so wie er in der App-Leiste in Teams erscheinen soll.
  • Kurzbeschreibung der App (80 Zeichen): Eine kurze Beschreibung für Ihre App, welche im Teams-App-Katalog erscheinen wird.
  • Ausführliche Beschreibung der App (4 000 Zeichen): Eine ausführliche Beschreibung für Ihre App, welche im Teams-App-Katalog erscheinen wird.
  • Datenschutzrichtlinie: Die Datenschutzrichtlinie für angepasste Teams-Apps in Ihrer Organisation (muss mit https:// beginnen). Wenn Sie keine separate Datenschutzrichtlinie haben, drücken Sie Enter und das Skript verwendet die standardmäßige SharePoint-Datenschutzrichtlinie von Microsoft.
  • Nutzungsbedingungen: Die Nutzungsbedingungen für angepasste Teams-Apps in Ihrer Organisation (müssen mit https:// beginnen). Wenn Sie keine separaten Nutzungsbedingungen haben, drücken Sie Enter und das Skript verwendet die standardmäßigen SharePoint-Nutzungsbedingungen von Microsoft.
  • Firmenname: Der Name Ihres Unternehmens, der auf der App-Seite im Teams-App-Katalog im Abschnitt „Erstellt von“ ersichtlich sein wird.
  • Firmen-Website: Die öffentliche Website Ihres Unternehmens (muss mit https:// beginnen), die mit dem App-Namen Ihres Unternehmens auf der App-Seite im Teams-App-Katalog im Abschnitt „Erstellt von“ verknüpft sein wird.
  • Symbole: Sie müssen zwei PNG-Symbole bereitstellen, mit denen Ihre Viva Connections-Desktop-App in Teams dargestellt wird. Ein farbiges Symbol mit 192 x 192 Pixel für den Teams-App-Katalog und ein monochromes Symbol mit 32 x 32 Pixel für die Teams-App-Leiste. Erfahren Sie mehr über die Richtlinien für Teams-Symbole.

All diese Informationen sind später aber auch einfach änderbar. Danach erhalten Sie ein ZIP-Paket mit der App selbst.

App in Teams bereitstellen

In der Anleitung wird geht es nun weiter mit dem Hochladen der App im Teams Admin Center. An dieser Stelle empfehle ich Ihnen jedoch, die App in das Teams Dev Center hochzuladen: https://dev.teams.microsoft.com:

Dann können Sie danach einfacher Änderungen an der App vornehmen und vor dem Deployment die Angaben überprüfen. Vor allem mit Umlauten hat das PowerShell-Script unter Umständen Probleme, diese können Sie hier nochmal korrigieren:

Vor dem richtigen Deployment können Sie die App über „Preview in Teams“ in Ihrem Teams-Client ansehen und überprüfen. Hier kann man vor allem die Wirkung der Icons (vor allem des Outline Icons) in verschiedenen Teams-Themes (Light, Dark) wirken lassen und eventuell korrigieren.

Wenn die App soweit korrekt konfiguriert ist, klicken Sie rechts oben auf „Distribute“:

Da Sie diese App nur innerhalb der eiigenen Organisation verwenden möchten, klicken Sie auf „Publish to your org“. Sie werden auf die Seite „Publish to org“ weitergeleitet, wo Sie auf den Text unter dem Icon klicken müssen:

Danach steht Sie im Teams Admin Center als neue App zur Verfügung und kann von einem Teams Administrator genehmigt werden.

Im Teams Admin Center taucht diese neue App nun auf und kann über Auswahl des Publishing Status genehmigt werden:

Wenn Sie später Änderungen an der App vornehmen, müssen Sie im Teams Admin Center diese Updates nach Senden der Aktualisierung aus dem Dev Center über denselben Weg freigeben.

Benutzern die App zur Verfügung stellen

Je nachdem, wie Ihre App Permission Policies aussehen, steht die App nun allen Benutzern zur Verfügung (Standardverhalten, aber nicht empfohlen!) oder Sie müssen die App in eine Ihrer Policies hinzufügen.

Damit kann ein Benutzer dann in seinem Teams Client die App finden und selbst hinzufügen:

Alternativ können Sie die App aber über eine Setup Policy bei allen oder bestimmten Benutzern ganz oben anpinnen:

Erstellen Sie hierzu unter „Setup Policies“ eine neue Policy für eine Gruppe an Benutzern oder passen Sie die Global Policy an. Dann klicken Sie auf „Add apps“ und suchen dort Ihre neu erstellte App, um sie hinzuzufügen und anschließend in der Reihenfolge nach oben zu verschieben.

Sobald die Policy bei den Benutzern angewendet wird, ist sie dann die erste App und stellt das Intranet, wie im allerersten Screenshot gezeigt dar und bietet über einen weiteren klick auf das App Icon auch das globale Navigationsmenü.

P.S.: Inzwischen funktioniert die App übrigens auch im Mobile Client!

Neuerungen in MS Teams im Dezember 2020

In aktueller Zeit werden wieder einige Neuerungen in MS Teams ausgerollt, von denen einige sehr interessant sind. Daher möchte ich die Gelegenheit nutzen, diese hier vorzustellen.

Neue Grafiken und Umbenennungen

Teilweise sind neue eckigere Icons an manchen Stellen zu sehen, wie hier beispielsweise im Chat:

Neue Buttons im Dark Theme
Neue Buttons im Light Theme

Nebenbei wurde nun auch die Planner-App umbenannt in „Tasks von Planner und To Do“. Etwas holprig, aber wahrscheinlich wird die App final nach dem Merge der beiden Umgebungen in To Do umbenannt.

Namensänderung der Planner App

Neue PreJoin-Experience

Die PreJoin-Experience ist die Oberfläche, die vor dem Teilnehmen eines Meetings erscheint. Diese wurde um größere Auswahlen mit textuellen Beschreibungen ergänzt:

PreJoin-Experience

Diese macht es nun deutlich einfacher, die aktuellen und möglichen Einstellungen zu erkennen und anzupassen. Und auch neue Möglichkeiten zu entdecken, wie z.B. „Raumaudio“. Hierbei handelt es sich um die Möglichkeit z.B. ein Teams Room Device als Audiogerät per Bluetooth zu verwenden.

Weiterhin können hier die Kamera eingestellt und die Hintergründe ausgewählt werden. Übrigens ist es derzeit immer noch nicht möglich zusätzliche Hintergründe global zu verteilen. Entweder muss dies jeder Benutzer selbst hinzufügen oder per GPO bzw. Softwareverteilung verteilt werden.

Übernahme von Meetings auf andere Geräte

Bisher war das Wechseln von Geräten auch schon möglich, beispielsweise konnte man ein Meeting am Telefon annehmen und dann am Desktop über den Meetingtermin oder den Chat auch teilnehmen und am anderen Gerät beenden.

Jetzt erhält man aber direkt den Hinweis, dass man auf einem anderen Gerät in einem Meeting ist und kann dieses dann übernehmen oder zusätzlich zum anderen Gerät teilnehmen:

Übernahme von Meetings – Ankündigung
Übernahme von Meetings – Einstellung

Breakout Rooms

Die wohl interessanteste Neuerung zurzeit sind aber wohl die Breakout Rooms. Diese erlauben es dem Organisator innerhalb eines Meetings Unterräume anzulegen und die Teilnehmer darauf zu verteilen. Im Meeting gibt es dazu einen neuen Button:

Breakout Rooms – Oberfläche

In dem erscheinenden Dialog lassen sich dann Räume erzeugen und die Teilnehmer automatisch auf die Räume verteilen:

Breakout Rooms erstellen

Oder man verteilt die Teilnehmer manuell auf selbst angelegte und auch benannte Räume:

Teilnehmer zuweisen

Wenn man mit der Verteilung fertig ist, kann man alle Räume starten oder auch nur einzelne:

Räume starten

Sobald ein Raum gestartet wurde, in den man eingeteilt wurde, erscheint die folgende Meldung und man wird nach ein paar Sekunden automatisch verschoben:

Benachrichtigung vor Verschiebung

Innerhalb des Raumes kann man jederzeit zur Hauptbesprechung zurückkehren und von dort auch wieder dem zugewiesenen Raum beitreten:

Zurück zum Hauptmeeting
Wieder in den Raum wechseln

Der Organisator kann über die Raumliste jederzeit in jeden einzelnen Raum eintreten und an den Gesprächen dort teilnehmen. Am Ende kann er die Räume auch schließen und damit alle Teilnehmer in die Hauptbesprechung zurückkehren. Auch eine Nachricht an alle Räume ist möglich.

Kontextmenü der Räume

Aber Achtung: Wer mit Warteraumfreigaben arbeitet (standardmäßig z.B. mit Gästen der Fall), der muss etwas aufpassen. Die erste Verschiebung des Gastes funktioniert ohne Warteraumfreigabe. Wenn der Gast sich jedoch selbst in die Hauptbesprechung oder in den zugewiesenen Raum begibt, muss dort jeweils jemand sein, der ihn zur Besprechung erneut zulassen kann. Sonst bleibt er im Warteraum. Der Organisator erhält die Nachricht nicht, wenn er sich nicht in dem gleichen Raum befindet!

WAP-Trust mit ADFS kann nicht mit secondary node aufgebaut werden

Etwas ungewöhnliches Szenario bei einem Kunden:

ADFS-Farm mit zwei Servern (Windows Server 2019) intern, wir nennen sie nun mal ADFS1 und ADFS2. Zusätzlich zwei Web Application Proxies (WAP1 und WAP2) in der DMZ.

ADFS1 ist der primäre Knoten in diesem Verbund. Aufgrund von Netzwerkanforderungen muss der WAP1 direkt mit ADFS1 sprechen (hosts-Datei) und der WAP2 direkt mit ADFS2. Bei WAP1 ist der Aufbau des Trusts einwandfrei gelaufen. Beim WAP2 schlägt das Hinzufügen zum ADFS mit einem HTTP-Fehler 400 (Bad Request) fehl.

Hintergrund: Der WAP2 erzeugt ein Client-Auth-Zertifikat und schickt dieses über den Endpunkt /adfs/proxy/establishtrust an den ADFS2. Da dieser nicht der primäre Knoten ist, schickt ADFS2 das Zertifikat über den Aufruf von /adfs/proxy/primarywriter/establishtrust an den ADFS1 weiter.

In diesem Aufruf ist nun der Hostname des Ziel-ADFS-Servers enthalten, in diesem Fall also ADFS1. Allerdings schlägt dieser fehl, da der ADFS-Server den Hostname mit den registrierten Hostnames abgleicht. Und wenn man sich mit Get-ADFSFarmInformation die registrierten Servernamen anschaut, steht dort der FQDN drin, also adfs1.firma.de.

Lösung: ADFS2 einreißen und neu zur Farm hinzufügen, aber diesmal mit dem FQDN des ADFS1, also adfs1.firma.de. Danach funktioniert auch der Aufbau des Trusts von WAP2 über den Stellvertreter ADFS1.

Und wo findet man diesen Fehler: Im AD FS Tracing des Event-Logs (das muss aktiviert werden) findet sich in diesem Fall eine Informations-Meldung mit ID 54:
“HTTPListener: Unexpected exception: The host name adfs1 in the incoming request did not match the AD FS host name.”

Merke: ADFS-Nodes immer mit FQDN des Primary Nodes hinzufügen.

DCs und RODCs per LDAP Query abfragen

Heute beschäftigte mich mal wieder das Thema, wie man effektiv alle schreibbaren Domain Controller und RODCs in einer Active Directory Domain abfragen kann. Hintergrund war in diesem Fall ein Tool, das für einen Benutzer die Werte von badPwdCount, badPasswordTime, lastLogon und lastLogoff abfragen kann, die in einem AD nicht repliziert werden. D.h. sie müssen von jedem DC abgefragt und der maximale Wert verwendet werden.

Und siehe da, ich fand eine sehr einfache Lösung:

Domain Controller sind automatisch Mitglied der AD-Gruppe “Domain Controllers” und RODCs sind Mitglied der Gruppe “Read-only Domain Controllers” und haben diese auch als primäre Gruppe gesetzt.

Da diese beiden Gruppen builtin sind, haben sie auch immer dieselben RIDs von 516 resp. 512. Damit können die DCs und RODCs sehr einfach über folgende LDAP Queries abgefragt werden:

primaryGroupId=516

für Domain Controller und

primaryGroupId=521

für ReadOnly Domain Controller. Viel einfacher geht es wohl nicht ;).

ADFS 2016: Invoke-AdfsFarmBehaviourLevelRaise schlägt fehl

Nachdem in einer größeren Farm alle ADFS-Server durch Windows Server 2016 ausgetauscht wurden, war das Anheben des Farm Behaviour Levels dran. In der Regel muss hierzu lediglich das Cmdlet Invoke-AdfsFarmBehavourLevelRaise ausgeführt werden, fertig.

Hier aber kam beim Aufruf des Cmdlets jedes Mal die Fehlermeldung:

Invoke-AdfsFarmBehaviorLevelRaise : Database upgrade could not be performed on localhost. Error: Unable to connect to the database. You may not have permission to create the AD FS configuration database in the specified SQL server. You can do one of the following: (1) have the SQL administrator grant permissions to you to create the AD FS configuration database in the specified SQL server or (2) have the SQL administrator create the AD FS configuration database by running  SQL scripts. Use the Export-ADFSDeploymentSQLScript to create the SQL scripts.

After the SQL administrator runs the scripts, try the command again specifying that the database is to be overwritten.

Die Accounts hatten alle die benötigten Rechte, daher war die Fehlersuche sehr schwer. Im Log des SQL Servers standen mehrere Fehlermeldungen:

Login failed for user 'DOMAIN\ADMINUSER'. Reason: Failed to open the explicitly specified database 'AdfsConfigurationV3'. [CLIENT: xx.xx.xx.xx]
Login failed for user 'DOMAIN\ADMINUSER'. Reason: Failed to open the explicitly specified database 'AdfsConfigurationV3'. [CLIENT: xx.xx.xx.xx] 
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Failed to open the explicitly specified database 'AdfsConfigurationV3'. [CLIENT: xx.xx.xx.xx] 
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Failed to open the explicitly specified database 'AdfsConfigurationV3'. [CLIENT: xx.xx.xx.xx] 

Das machte die Fehlersuche auch nicht einfacher, denn die Datenbank wurde gar nicht erstellt.

Die Lösung

Nach einem Blick in die Dokumentation des Cmdlets löste sich das Problem per Try-And-Error, denn in dieser Umgebung war die Konstellation etwas komplexer: Die ADFS-Datenbank lag auf einem eigenen Always-On Cluster, das scheint bei dem Cmdlet für Authentifizierungsprobleme zu sorgen.

Die Nutzung der Parameter Credentials und ServiceAccountCredentials, ersterer mit einem Admin-Account, zweiterer mit dem Service Account lief das Cmdlet fehlerfrei durchlaufen:

$admincred = Get-Credential #Admin-Account angeben
$cred = Get-Credential #Service Account angeben
Invoke-AdfsFarmBehaviorLevelRaise -ServiceAccountCredential $cred -Credential $admincred

SharePoint WebTemplate Bug: Listenansichten mit mehreren WebParts

Szenario

Es wird eine Site in SharePoint 2013 erzeugt, die später als Template abgespeichert und mehrfach instanziiert werden soll (z.B. für Projekt-Sites). In dieser Site existieren mehrere Listen. In den Listenansichtsseiten werden jedoch weitere Listenwebparts eingebaut, um z.B. auf einer Page Dokumente und Aufgaben anzeigen zu lassen. WICHTIG: Es werden keine neuen Pages in der Pages-Library erzeugt, sondern direkt in einer Bibliotheksansicht zusätzliche Listen-WebParts eingebaut.

Diese Site wird dann als Template abgespeichert und aus diesem Template eine neue Site erzeugt.

Das Problem

Auf der neu erzeugten Site sind die zusätzlichen Listen-WebParts in den Bibliotheksansichten verschwunden, nur noch das WebPart der Bibliothek/Liste ist vorhanden, zu dem die Ansichtsseite gehört.

Die Lösung

In der ursprünglich für das Erzeugen des Templates genutzten Site muss bei allen WebParts die WebPart-Einstellung “Chrome Type” z.B. auf “Nur Titel” gesetzt werden. Dann werden alle WebParts in das Template aufgenommen und daraus erzeugte Sites beinhalten auch wieder die zusätzlichen WebParts.

AADConnect Upgrade fails: “the provided user is not a member of the enterprise admins group”

In irgendeiner Version seit 1.1.5xx hat Microsoft im Upgrade-Wizard von AADConnect offensichtlich den Code zur Prüfung des Enterprise Admin Accounts geändert, den man im Upgrade Wizard angeben muss.

Unter bestimmten Umständen kann es passieren, dass Accounts nicht funktionieren, obwohl sie Mitglieder der Enterprise Admins-Gruppe des Forests sind, so geschehen jetzt aktuell in einer meiner Umgebungen.

Das Szenario:

  • Der Forest besteht aus einer Root-Domain (z.B. contoso.com) und mindestens einer Subdomain (z.B. corp.contoso.com)
  • Der verwendete administrative Account ist Mitglieder der Gruppe “Enterprise Admins” in der Root-Domain
  • Der verwendete administrative Account befindet sich selbst in einer Subdomain

Und genau der letzte Punkt ist das Problem: Im Code versucht der Wizard die Gruppenmitgliedschaften des angegeben Users aufzulösen, sucht sich hierzu jedoch ein neues DirectoryEntry-Objekt mit Hilfe des samAccountNames und unter Verwendung einer Verbindung zur Root Domain. Und damit erhält man meist keinen User und damit keine Gruppenmitgliedschaften und daher erscheint die Fehlermeldung.

Die einfache Lösung: Der verwendete Account muss sich auch in der Root-Domain befinden, also im Zweifelsfall einen separaten Account anlegen oder den Builtin-Administrator der Root-Domain verwenden.

Kalenderliste mit Serienterminen darstellen

Heute mal wieder eine Anforderung eines Kunden: Auf der Startseite von SharePoint sollten die nächsten anstehenden Termine im Unternehmen angezeigt werden und zwar als Liste, da die Kalenderansicht zu viel Platz weg nimmt.

Problem war dabei, dass in dieser Liste die Serientermine nicht korrekt angezeigt wurden, lediglich der erste Termin erschien, aber alle weiteren Instanzen wurden nicht mehr dargestellt.

Das Phänomen lässt sich leicht nachstellen: Es gibt zwar die Ansicht “Aktuelle Ereignisse”, die auch Serientermine korrekt darstellt, sobald man diese kopiert, ist das Verhalten dasselbe, alle kommenden Serientermine tauchen nicht mehr in der Liste auf. Hintergrund ist, dass ein Serientermin ein einziges Element ist, dass mehrfach abgefragt werden muss. Und die dazu notwendigen Einstellungen können über die Oberfläche nicht gesetzt werden.

Wird die Ansicht also kopiert und modifiziert, muss z.B. per PowerShell das WebPart und die dahinterliegende View verändert werden:

$web = Get-SPWeb "[Url zur Site]"
 $wpm = $web.GetLimitedWebPartManager("[relative Url zur ASPX-Datei]","Shared")
 $wp = $wpm.WebParts | ?{$_.Title -eq "[Titel des WebParts]"}
 $wp.ViewFlags = $wp.ViewFlags -bor [Microsoft.SharePoint.SPViewFlags]::RecurrenceRowset
 $wp.View.Query = "<Where><DateRangesOverlap><FieldRef Name="EventDate" /><FieldRef Name="EndDate" /><FieldRef Name="RecurrenceID" /><Value Type="DateTime"><Now /></Value></DateRangesOverlap></Where><OrderBy><FieldRef Name="EventDate" /></OrderBy>"
 $wpm.SaveChanges($wp)

Dies setzt die notwendigen Einstellungen und danach sollten die Serientermine korrekt dargestellt werden.

Installation von Visual Studio 2015 und SharePoint Server 2013

Heute wollte ich eine neue Entwicklungsumgebung mit den aktuellen Produkten aufbauen:

  • Windows Server 2012 R2
  • SharePoint Server 2013 SP1
  • Visual Studio 2015

Da das Herunterladen des SharePoint Images noch einige Zeit dauerte, habe ich in der Zwischenzeit Visual Studio 2015 installiert. Im Nachhinein hat sich dies als sehr schlechte Idee herausgestellt.

Denn nach dem Ausführen des Prerequisite Installer hat das Setup weiterhin hartnäckig bemängelt, dass .NET 4.5 nicht installiert sei, obwohl dies ja bei Windows Server 2012 R2 standardmäßig installiert ist. Auch diverse Tipps in Foren, wie das Neuinstallieren von .NET oder das Umbenennen der ServerManager.exe in ServerManagerCMD.exe hatten nicht geholfen.

Zu guter Letzt habe ich den Grund doch noch gefunden: VS 2015 installiert .NET 4.6 und hebt damit auch gleich die Versionsangabe von .NET 4 darauf an, die das Setup ausliest. Und damit kommt selbiges noch nicht klar, da es eine Versionsnummer mit 4.5 erwartet.

Doch dies lässt sich glücklicherweise für das Setup über die Registry beheben. Hierzu muss der Wert von “Version” im Key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client” in die Versionsnummer “4.5.50501” geändert werden.

Aufgrund der Berechtigungen gestaltet sich dies leider etwas schwieriger. Zunächst muss der Besitz des Schlüssels übernommen werden:

Danach muss die Berechtigung für die Administratoren-Gruppe erweitert werden:

Zu guter Letzt wird der Wert geändert:

Danach kann das Setup gestartet werden und sollte ohne Probleme die Key-Abfrage zeigen. Nicht vergessen nach der Installation die Versionsnummer wieder auf den ursprünglichen Wert zu ändern!