Frühling in der Cloud

Der meteologische Frühling hat begonnen und auch in der Office365 Cloud tut sich so einiges.

Gruppenbenachrichtigungen

So hat Anfang der Woche ein neues Icon Einzug in die Benachrichtigungsleiste von Office365 gehalten: Gruppenbenachrichtigungen.

image

Allerdings ist die Anzeige erst einmal noch ein wenig ernüchternd: image

Es ist auch noch nicht ganz klar, was für Meldungen dort mal auftauchen könnten – aktuell werden da noch keine Meldungen angezeigt, das Icon ist also nur für Zukünftige Zwecke schon mal da.

Offenbar hat man auch beim Office365 Team eingesehen, dass eine Anzeige des Icons nicht Sinnvoll ist, wenn man da nichts anzeigen kann. Nachdem also das Icon im Laufe der Woche nun den Weg auf alle meine Office365 Seiten gefunden hat, ist es nun wohl wieder auf dem Rückmarsch, nicht zuletzt aufgrund des Feedbacks aus der Community.

Office365 Profile

Das klassische Profil in Office365, welches über https://busitec-my.sharepoint.com/PersonImmersive.aspx zu erreichen ist, sieht ja eher so aus:

image

Nun gibt es aber offenbar eine neue Profil-Seite (https://portal.office.com/profile), die zudem auch noch responsive gestaltet ist. Zu erreichen ist die Seite auch aus dem Menu, wenn man auf dem Zahnrad auf Office365 Einstellungen geht und dann “Ich” auswählt.

image

image

Interessant ist dabei auch, dass ich hier Informationen über mein Konto finden kann, z.B. welche Lizenzen ich alle zugweisen habe.

image

Mail (aka Outlook)

Das Outlook web Access horcht nun nicht mehr auf den Namen “Outlook”, sondern nur noch “Mail”. (Viel Spaß für alle, die z.B. Handbücher oder Schulungsmaterialen haben, die auf “Outlook” verweisen Smiley)

Dort gibt es nun ein neues Menu für die Optionen. Das dürfte die Vorbereitung sein, dass bald auch Funktionen wie Clutter ausgerollt werden. Wie man schon von diversen Screenshots gesehen hat, kommt das in dem E-Mail Menu zwischen den “Automatischen Antworten” und den “Posteingangsregeln”.

image

Standardeinstellungen Dokumentenbibliotheken

Offenbar ist schon seit einiger Zeit standardmäßig Versionierung für alle Dokumentbibliotheken in Office365 aktiv. Das kann natürlich bei vielen Änderungen an Dokumenten a) zu einem etwas größeren Platzbedarf führen und b) kann es das Laden der Liste/Dokumente unter Umständen auch negativ beeinflussen.

Deshalb hat Microsoft nun die Anzahl der Versionen standardmäßig auf 500 begrenzt – zumindest für alle neu angelegten Site-Collections.

image

 

Das sind zumindest die Dinge, die mir so ad-hoc aufgefallen sind, die sich alle innerhalb einer Woche getan haben. Viel Spaß beim selbst erkunden.

SharePoint PeoplePicker mit mehreren Domänen

Hier ein Update zu meinem Post, in dem ich schon mal beschrieben habe, wie man von einem SharePoint System eine andere Domäne mit durchsucht. Ich kannte bis dato nur den Weg über das gute alte STSADM; aber natürlich geht es auch mit PowerShell!

Und sogar noch viel besser. Mit der PowerShell kann ich in SharePoint mehr als eine Domäne durchsuchen. Und so geht es:

$wa = Get-SPWebApplication http://sp2013.dev-acme.local 

$adsearchobj = New-Object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain
$userpassword = ConvertTo-SecureString "MeinPasswort" -AsPlainText – -Force
$adsearchobj.DomainName = "acme.local"
$adsearchobj.ShortDomainName = "ACME Corporation"
$adsearchobj.IsForest = $false #$true for Forest, $false for Domain
$adsearchobj.LoginName = "devlookup"
$adsearchobj.SetPassword($userpassword)

$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($adsearchobj)
$wa.Update()

Das ist zwar insgesamt etwas länger, aber deutlich verständlicher als die Zeile

STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "domain:acme.local,acme\devlookup,MeinPasswort" -url http://sp2013.dev-acme.local

Debuggen von SharePoint-Apps

Vor einiger Zeit wurde ich gefragt: “Wie kann ich eigentlich eine SharePoint(-Hosted) App debuggen?”.

Die erste Antwort ist natürlich: Developer Tools! Alle Browser verfügen heute über Developer-Tools, die das Debugging von JavaScript Anwendungen erlauben.

imageimage

Wenn ich die Anwendung im Browser ausführe kann ich in den Quellcode springen und dort – wie in Visual Studio – Breakpoints setzen. Anschließend muss ich die Seite ggf. noch einmal laden, damit der JavaScript-Code noch einmal ausgeführt wird und mein Breakpoint erreicht wird.

Anschließend kann ich den Wert von Variablen ansehen oder den Call-Stack betrachten und natürlich kann ich durch meinen Code-Steppen und genau die Ausführung meines Codes untersuchen.

image

Es gibt aber auch noch einen andere Weg: Visual Studio!

Wenn ich den IE als Browser für meine Anwendung verwende, dann kann ich meine Breakpoints auch direkt in Visual Studio in meinem JavaScript Code setzen. (Wenn man mehrere Browser installiert hat, habe ich in einem früheren Beitrag beschrieben, wie ich in einem SharePoint-App-Projekt den zu verwendenden Browser festlegen kann).

Anschließend kann ich meine Anwendung direkt in Visual Studio starten und sobald ich meinen Breakpoint erreiche kann ich meinen JavaScript Code in Visual Studio debuggen – mit alle Debugging-Funktionen die ich in Visual Studio zur Verfügung habe.

image

Ein Vorteil bei der Verwendung von Visual Studio ist, dass ich nicht zunächst die JavaScript Datei einmal im Browser geladen haben muss um den Breakpoint zu setzten.

Browser für SharePoint-Apps festlegen

Als Web-Entwickler bin ich es inzwischen gewohnt, dass ich in Visual Studio beim Starten meiner Web-Anwendung auswählen welcher Browser für die Anzeige verwendet werden soll.

image

Leider sieht das Start-Button bei einem SharePoint-Projekt ein wenig anders aus.

image

Es wird immer der Browser verwendet, den ich als Default-Browser in Windows eingestellt habe. Schade wenn ich die Anwendung mal mit einem anderen Browser testen will – dann muss ich den Browser manuell starten und die URL per Copy & Paste dort einfügen; insbesondere weil die URL bei SharePoint-Hosted Apps ja nun auch nicht gerade intuitiv ist.

Aber es gibt eine Lösung. Wenn ich die Projekteigenschaften anzeige, dann kann ich bei SharePoint-Projekten auswählen welcher Browser beim Starten verwendet werden soll.

image

Super!!

Dokumentsets im Eigenbau

Dokumentsets sind ein sehr schicke Funktion von SharePoint Server. Leider gibt es die nur in der Server-Version – also nicht wenn man nur Foundation einsetzt.

Was also tun, wenn der Kunde nur eine Foundation hat, aber Anforderungen hat, die nach den Eigenschaften eines Document-Sets schreien?

Die Anforderungen

Vielleicht zunächst zu den Anforderungen des Kunden. Die Anforderung war, dass es ein Dokument gibt, zu welchem Anlagen existieren. Also eine Klassischer Master-Detail Beziehung zwischen den Dokumenten.

SharePoint kennt ja durchaus Anlagen – aber nur für Listenelemente, nicht bei Dokumenten. und Anlagen habe den Nachteil, dass es keine Versionierung und eigene Meta-Daten gibt. Das ist irgendwie doof. Schöner wäre es, wenn man also zu einem Dokument beliebig viele Anlagen anfügen könnte.

Natürlich hat mir diese Frage keine Ruhe gelassen und ich habe mir gedacht, dass sich das doch recht einfach lösen lassen muss.

Ein Lösungspfad

Fangen wir einmal ganz einfach an. Zuerst einmal brauchen wir zwei Dokument-Bibliotheken, eine für die Dokumente und eine für die Anlagen. In der Bibliothek der Anlagen wird dann eine Nachschlage-Spalte hinzugefügt, die auf die Dokumente verweist. Somit kann man also Anlagen hochladen und die mit einem Dokument verknüpfen.

doc_set_diy_01

Als nächstes sollten die Anlage immer beim jeweiligen Dokument mit angezeigt werden. Dazu wir die Standard-Ansicht des Dokuments bearbeitet und ein App-WebPart für die Anlagen Hinzugefügt.

doc_set_diy_02

Nun muss an das WebPart noch ein Filter übergeben werden. Dazu wird die ID des aktuellen Dokuments übergeben und in der Liste der Anlage in der Spalte QM-Dokumente gefiltert.

doc_set_diy_03

Wenn man nun also ein Dokument öffnet, sieht man nur die Anlage, die mit diesem Dokument verbunden sind.

Allerdings hat diese Lösung noch einen Haken: sie ist unhandlich in der Pflege. Wenn man eine neue Anlage zu eine Dokument hinzufügen will, dann muss man die Anlage in die Liste der Anlagen hochladen und in den Meta-Daten auf das Dokument verweisen. Das ist irgendwie doof. Besser wäre es ja, wenn man z.B. in der Detail-Ansicht des Dokuments sagen könnte “bitte eine neue Anlage für dieses Dokument hochladen”.

Das Customizing

Mit ein wenig JavaScript kann man das Handling der Lösung vereinfachen. Zunächst wird jQuery, ein File-Input Element und ein Button gebraucht.

<script type="text/javascript" src="https://mytenant.sharepoint.com/qm/scripts/jquery-1.8.2.min.js"></script>
<input type="file" id="fileSelectorInput">
<input type="button" onClick="javascript: DoUpload();" value="Go!">

Nun folgt also die Magie. Die liegt hier natürlich in der Funktion DoUpload. Hier wird zunächst die Datei aus dem Dateisystem gelesen und dann als ByteCharacter-Array an eine weiter Funktion übergeben.

function DoUpload() {
    var fileInput = jQuery('#fileSelectorInput');

    var file = fileInput[0].files[0];
    var reader = new FileReader();
    reader.onload = function (result) {
         var fileName = '',
         libraryName = '',
         fileData = '';
 
        var byteArray = new Uint8Array(result.target.result)
        for (var i = 0; i < byteArray.byteLength; i++) {
            fileData += String.fromCharCode(byteArray[i])
        }
        
        DoUploadInternal(file.name, fileData);
    };
    reader.readAsArrayBuffer(file);
}

Soweit ist ja noch alles ganz Simple. Als nächstes wird die Datei mittels JSOM in den SharePoint geladen, um direkt auch die Meta-Daten setzen zu können.

Zunächst wird die ID des aktuellen Dokuments aus der URL gelesen und der Wert des Feldes QMName aus dem Anzeigeformular. Denn wir wollen der Anlage nicht nur einen Verweis auf das aktuelle Dokument geben, sondern auch die Meta-Daten aus dem Feld QMName mit an die Anlage übergeben.

JSRequest.EnsureSetup();
var qmName = jQuery('h3:contains("QM Name")').closest('td').next('td').text();
var qmDokumentId = JSRequest.QueryString["ID"];

Nun brauchen wir einen ClientContext, damit wir eine neue Datei für SharePoint anlegen können. Dort fügen wir dann das Character-Array unserer Datei als Content an.

clientContext = new SP.ClientContext.get_current();
var oWebsite = clientContext.get_web();
var oList = oWebsite.get_lists().getByTitle("QM-Anlage");

var fileCreateInfo = new SP.FileCreationInformation();
fileCreateInfo.set_url(fileName);
fileCreateInfo.set_content(new SP.Base64EncodedByteArray());

for (var i = 0; i < fileContent.length; i++) {
    fileCreateInfo.get_content().append(fileContent.charCodeAt(i));
}

newFile = oList.get_rootFolder().get_files().add(fileCreateInfo);
clientContext.load(newFile);

Nun müssen wir noch die Meta-Daten setzen. Dazu holen wir zunächst alle Feld-Informationen und setzen dann den Wert für QMName und erstellen einen Lookup auf das aktuelle Dokument.

item = newFile.get_listItemAllFields();
clientContext.load(item);

item.set_item("QMName", qmName);
var object = new SP.FieldLookupValue();
object.set_lookupId(qmDokumentId);
item.set_item("QMDokument", object);
item.update();

clientContext.executeQueryAsync(successHandler, errorHandler);

Am Schluss wird das Ganze dann als asynchrone Query an den Server gesendet. Im successHandler wird dann noch die aktuelle Seite aktualisiert, damit das neu hinzufügte Dokument auch in der Liste erscheint.

SP.UI.ModalDialog.RefreshPage(SP.UI.DialogResult.OK); 

Fazit

Mit ein bisschen Creativität und ein wenig JavaScript Anpassungen kann man schon ganz ordentlich etwas aus SharePoint heraus kitzeln.

doc_set_diy_04

SharePoint und Domänen mit einseitiger Vertrauensstellung

In komplexeren Systemumgebungen kann es schon mal vorkommen, dass es mehr als eine Active Directory Domäne gibt.

In meinem Fall gibt es neben der Produktiven Domäne acme.local noch eine Domäne für den Entwicklungsbereich dev-acme.local. Zwischen den beiden Domänen gibt es eine einseitige Vertrauensstellung, so dass man sich mit seinem Account eiben@acme.local auch an dev-acme.local anmelden kann, nicht aber mit deinem dev-acme Account an der acme Domäne. Soweit alles klar.

Was aber, wenn ich in der dev-acme.local Domäne einen SharePoint stehen habe, auf den ich auch mit den acme.local Accounts zugreifen will? Wenn in SharePoint Berechtigungen vergeben werden, dann schlägt SharePoint den Account in der Domäne nach. In diesem Fall ist der SharePoint in der dev-acme.local Domäne installiert und läuft natürlich auch mit entsprechenden Service-Accounts (wie dev-acme\spAppPool). Dieser kann aber aufgrund der Vertrauensstellung keine Accounts aus acme.local nachschlagen, da dieses nachschlagen ja unter der Identität des Application-Pools der Web-Anwendung stattfindet (und die Domäne acme.local kann aus Sicherheitsgründen nur von Authentifizierten Benutzern abgefragt werden).

Was nun?

Zum Glück kann man SharePoint zu genau diesem Zweck sagen, dass für den Zugriff auf eine bestimmte Domäne ein anderer Account verwendet werden soll. Somit kann ich also auch auf andere Domänen zugreifen.

Wie geht das also?

Zunächst brauche ich einen Account in der acme.local Domäne, mit dem ich Benutzerkonten nachschlagen kann. Dafür reicht ein normaler Benutzer, der eigentlich keine besondere Rechte benötigt (außer dass er halt auf das AD zugreifen können muss). Ich habe den mal devlookup genannt.

Bevor ich SharePoint diesen Account für die Lookups beibringen kann, muss ich noch einen Verschlüsselungsschlüssel erstellen.

STSADMstsadm.exe -o setapppassword -password MeinGeheimerSchluessel

Nun kann ich SharePoint mitteilen, dass für die Web-Application mit der URL sp2013.dev-acme.local beim Zugriff auf die Domäne acme.local das Konto acme\devlookup verwendet werden soll:

STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "domain:acme.local,acme\devlookup,MeinPasswort" -url http://sp2013.dev-acme.local

Unglaublich, dass diese Einstellung nur mit dem guten alten STSADM geht. Aber so ist es halt nun mal – auch in Zeiten von PowerShell.

AutoResponder mit Fiddler

Vor einigen Tagen sollte ich einen Proof-Of-Concept erstellen, ob man ein System XYZ z.B. in BizTalk anbinden könnte. Das System XYZ bietet dazu eine Schnittstelle an, welche über HTTP mit JSON Nachrichten angesprochen werden kann und auch mit JSON wieder antwortet.

Also mal eben eine kleine BizTalk-Lösung bauen, um zu testen ob man diese JSON Nachrichten richtig erstellen und die Antworten auch richtig verarbeiten kann. Als erstes wird in Azure eine BizTalk 2013 R2 Entwicklungsumgebung erstellt. Das geht recht schnell, innerhalb von knapp 15 Minuten ist die Umgebung verfügbar – cool.

So, also nächstes musste also die Lösung erstellt werden. Aber die Frage ist: wie kann ich testen, ob nun aus BizTalk die Services richtig angesprochen werden und auch die Antwort dann von BizTalk richtig verarbeitet wird? Das System XYZ läuft beim Kunden On-Premise, da habe ich also von Azure aus keinen Zugang. Und mal eben XYZ installiert ist ja auch nicht so einfach, da brauche ich einen SQL-Server, Tomcat … und das ganze Konfigurieren – und alles nur für einen Proof-Of-Concept? Nein Danke!

Und mal wieder ist Fiddler der Retter!

Ich habe also meine Lösung mit BizTalk gebaut und dann auch komplett im BizTalk deployed. Nur leider steht mir ja das System XYZ nicht zur Verfügung, welches in eigentlich ansprechen wollte. Also mal eben Fiddler auf dem Server installiert und dann mit Fiddler das System simuliert. Anstatt dem System XYZ hat Fiddler auf die Aufrufe, welche für XYZ bestimmt waren, abgefangen und beantwortet. Für BizTalk erfolgte das komplett transparent – sweet!

Und wie geht das?

Ganz einfach! Fiddler hat eine Funktion „AutoResponder“. Damit kann Fiddler automatisch auf eingehende Nachrichten reagieren und antworten. Hier haben ich also für die HTTP Aufrufe entsprechende Regeln eingerichtet, die zum einen überprüfen ob die URL http://system-xyz:9090/abc/ aufgerufen wurde und ob im Body des Requests clazz=foo steht. Wenn ja, dann wird der Inhalt der Datei foo_response.json zurückgefliefert. Mit einer zweiten Regeln prüfe ich dann analog ob im Body clazz=bar steht und antworte mit bar_response.json.

fiddler_01

Alle anderen Anfragen werden ganz normal weitergegeben. Für BizTalk ist es also vollkommen transparent, ob nun das System XYZ oder ein anderes tatsächlich auf die Anfragen reagiert. Es muss ja noch nicht einmal der Server-Name existieren, da der Request ja direkt von Fiddler abgefangen wird.

Cool! Somit kann ich testen, ob meine Anwendung richtig mit dem System XYZ sprechen würde, auch wenn ich das System nicht habe – ich muss „nur“ wissen wie die Requests und die Responses ausseen würden.

Post-Migration Reporting

Nach der Pflicht kommt bekanntlich die Kür. So ist es auch bei der Migration von SharePoint.

Vor einiger Zeit hatten wir für einen Kunden Inhalte von einer bestehenden SharePoint 2007 Farm zu einer SharePoint 2013 Farm migriert – mit ShareGate. Dabei wurden diverse Listen und Sites migriert. Am Ende hatten wir 11 Migrationen mit ShareGate durchgeführt und alle Inhalten waren erfolgreich übertragen.

Nun geht es also darum die Migration ein klein wenig aufzuarbeiten und zu dokumentieren. Praktischerweise kann man sich die Migrations-Reports in ShareGate als Excel-Datei speichern. Nun habe ich also alle Informationen in 11 Excel-Dateien. Nun ist also die Frage: wie kann ich das am besten aufbereiten?

Hierzu fällt die Wahl auf eines meiner Lieblingswerkzeuge (abgesehen von Visual Studio): Excel!

Mit den neuen BI Funktionen von Excel ist es ein leichtes die Daten aufzubereiten.

sg_mig_rep

Aber ganz in der und der Reihe nach.

Zunächst einmal habe ich also die 11 Excel-Dateien aus ShareGate.

sg_mig_01

sg_mig_02

Hier fällt schon auf, dass die Daten noch ein wenig überarbeitet werden müssen. So wird das Datum hier aktuell noch als Zahl angezeigt. Das ist kein Problem, einfach die Spalte entsprechend formatieren.

Aber wie kann ich nun eine kombinierte Auswertung über alle 11 Dateien machen? Hier kommt Power Query zum Einsatz.

Zunächst einmal beginne ich damit eine einzelne Datei in Power Query einzulesen.

sg_mig_03

sg_mig_04

Nun kann ich sagen, dass die erste Zeile als Header interpretiert werden soll, und die Spalte Date vom Typ Datum/Uhrzeit ist.

sg_mig_05

Nun kann ich mir die Aufbereitung als Script im Erweiterten Editor ansehen. Hier steht nun als Quelle meine Excel-Datei drin. Das kann ich durch einen Parameter ersetze, so dass ich die Aufbereitungsschritte als Funktion in Power Query speichern kann, die als Parameter den Namen der Datei entgegen nimmt, auf die diese Schritte angewandt werden sollen.

sg_mig_06

Nun kann ich also die Abfrage schließen und erstelle eine neue Power Query Abfrage. Dieses mal öffne ich aber nicht eine einzelne Datei, sondern den Ordner in dem sich meine ganzen ShareGate-Reports befinden.

sg_mig_07

Nun habe ich also eine Liste aller Dateien. In dieser Liste kann ich nun die Spalten “Folder Path” und “Name” zusammenfassen, so dass ich den kompletten Pfad bekomme.

sg_mig_08

Anschließend kann ich noch eine benutzerdefinierte Spalte hinzufügen. Hier rufe ich meine als Funktion abgespeicherte Abfrage auf, und übergebe dieser Funktion den gerade zusammengebauten Pfad.

sg_mig_09

Als Ergebnis habe ich nun eine neue Spalte (“Custom”) vom Typ “Table”. Dabei handelt es sich um eine geschachtelte Tabelle – also jede Zeile hat nun eine Tabelle, die den Inhalt der Datei darstellt, der ja mit meine Funktion schon ein wenig aufbereitet wurde.

Eine der absolut coolsten Funktionen von Power Query ist es nun, dass ich diese geschachtelte Tabelle expandieren kann.

sg_mig_10

Wenn ich das mache, dann erhalte ich eine alle Daten aus allen Dateien. Jeder Datensatz hat dabei auch die Daten, die ich in der Liste der Dateien auch schon hatte …

sg_mig_11

Diese Daten kann ich nun aus der Power Query Abfrage in mein Excel Arbeitsblatt übernehmen. Dann noch schnell eine PowerView über die Daten gestülpt – fertig!

Natürlich hätte man das auch anders machen können. Man hätte die 11 Dateien geöffnet und die Daten per Copy & Paste in ein neues Arbeitsblatt eingefügt. Anschließend hätte man ja auch eine Liste mit allen Daten, die man mit PowerView anzeigen lassen kann.

Aber was ist, wenn dann noch 3 Dateien dazu kommen? Kein Problem: einfach die Daten ebenfalls einfügen/anfügen.

Und was ist, wenn eine der Reports nicht mit einbezogen werden soll, weil der von einer Testmigration stammt? Dann müsste man die dafür notwendigen Datensätze aus der Liste löschen.

Durch den Einsatz von Power Query sind in meiner Excel-Datei alle Schritte für die Aufbereitung der Daten gespeichert. Ich kann nun hingehen und ganz andere Reports in dem Ordner ablegen, meine Excel Datei öffnen und auf “Alle Daten aktualisieren” in Excel klicken. Dann werden alle Schritte für die Aufbereitung erneut durchgeführt. Es werden also alle Dateien aus dem Verzeichnis aufgelistet werden, der Pfad wird zusammengestellt, meine benutzerdefinierte Funktion wird ausgeführt und die geschachtelte Tabelle wird expandiert. Schließlich werden die Daten in dem Excel-Arbeitsblatt aufgrund der Power Query Abfrage aktualisiert und die Grafik in dem PowerView wird automatisch aktualisiert. Und das Ganze passiert wie von Geisterhand.

Single-Sign-On & SharePoint

Auch wenn in vielen Unternehmen der Internet-Explorer quasi Standard ist, so ist der Interner-Explorer schon lange nicht mehr die Voraussetzung dafür, dass man sich an SharePoint ohne weitere Anmeldung mit seinen Windows-Credentials anmelden kann. Eigentlich hat das nichts mit SharePoint direkt zu tun, sondern betrifft Web-Anwendungen im allgemeinen.

Um sich automatisch bei SharePoint anzumelden (ich bleibe mal bei SharePoint), muss auf der Server-Seite die Windows Integrierte Anmeldung verwendet werden. Dabei werden die Windows-Credentials vom Client an den Server gesendet und zur Authentifizierung verwendet. Früher beherrschte lediglich der Internet Explorer die Weitergabe von Credentials, das hat sich (schon vor längerer Zeit) geändert. In zwischen beherrschen auch Firefox, Chrome und Safari die Windows Integrierte Anmeldung.

Beim Firefox muss dazu angegeben werden, für welche Domänen Firefox Authentifizierungsinformationen weitergibt. Das entspricht quasi den Zonen-Einstellungen des Internet-Explorers. Dazu muss im Firefox zunächst mit about:config die erweiterten Einstellungen geöffnet werden. Anschließend kann man mit den beiden Einstellungen network.negotiate-auth.trusted-uris (für Kerberos Authentifizierung) und network.automatic-ntlm-auth.trusted-uris (für NTLM Authentifizierung) die Domänen angeben, für die die Authentifizierung erlaubt sein soll. Bei mehreren Domänen kann man die mit Komma trennen.

Chrome bedarf keinen weiteren Einstellungen, hier funktionieren NTLM und Kerberos direkt. Beim Safari funktioniert nur Kerberos, wenn man bereits über ein Kerberos-Ticket verfügt.

Damit steht also der großen Browser-Vielfalt nicht mehr im Wege.