blog.atwork.at

news and know-how about microsoft, technology, cloud and more.

Delve und der Office Graph

Wednesday, October 1, 2014 8:00 AM Martina Grom
Wer kennt bereits Delve”? Das ist der neue Name von Oslo”. Ok, wer von Oslo” noch nichts gehört hat: Project Oslo” wurde im März auf der Microsoft SharePoint Conference vorgestellt. Damit wird der Office Graph” innerhalb von Office 365 bezeichnet. Hier finden Sie alle Infos über Delve und den Office Graph!
Cloud | Exchange | Microsoft | Office365 | SharePoint | Social | Yammer
mehr

Office 365 DNS Checks

Monday, August 18, 2014 9:18 AM Christoph Wilfing
Office 365 wird ständig verbessert. In jeder Ecke tut sich etwas und viele kleine Verbesserungen bemerkt man erst, wenn man direkt mit der Nase drauf gestoßen wird. Mir ist heute zum Beispiel in der DNS Domain Verwaltung eine kleine aber feine Verbesserung aufgefallen. Bisher konnte man beim einbinden seiner Custom Domains einen Domainzweck festlegen. Es gibt hier zur Auswahl Exchange, Lync, Sharepoint. Danach werden einem die dafür notwendigen DNS Einträge angezeigt. Oft ist es aber so, das man gewisse Records noch nicht, oder generell gar nicht eintragen will. Ein Beispiel ist der Autodiscover oder MX Eintrag. Dieser kann manchmal nicht einfach sofort geändert werden, in einem Hybrid Umfeld muss Autodiscover sogar On-Premises bleiben. Trotzdem beschwert sich die DNS Verwaltung mit einem unschönen "Possible Service issues" Fehler. klickt man dann auf Fix Issues kriegt man die schöne Liste an DNS Einträgen die zu setzen wären und auch genau welcher Eintrag nicht stimmt. In meinem Fall kann ich aber Autodiscover nicht umlegen und bin daher eigentlich frustriert. Jetzt hat sich da rechts ein kleines Hackerl eingeschlichen. "Don't check this domain for incorrect DNS Records." Hey cool - Einfach Hackerl setzen und schon ist der Fehler in der Domainüberprüfung weg. Einziger Pferdefuß ist, dass man damit auch wirkliche Fehler die eventuell bei DNS Zonen Änderungen passieren, versteckt. Falls so etwas vermutet wird, einfach in der Liste der Domains auf find and fix issues klicken und das Hackerl wieder rausnehmen. Dann wird auch sofort wieder überprüft welche Records korrekt oder falsch sind. LG Christoph
Cloud | Microsoft | Office365
mehr

DirSync und Proxy Einstellungen

Saturday, August 16, 2014 7:13 PM Christoph Wilfing
Gerade in großen Umgebungen gibt es neben einigen Firewalls sehr oft natürlich auch HTTP / HTTPS Proxy Server die zur Sicherheit den Verkehr von Clients nach extern überprüfen sollen. Gerade wenn sie Dirsync im Einsatz haben kann das häufig zu Konfigurationsproblemen führen und führt zu einigen Verwirrungen. Das Problem? Ihr Dirsync Server steht im internen LAN und muss aber für die Synchronisation mit dem Azure Active Directory mit dem Internet kommunizieren. Der Firewall Mensch sagt aber "nein - verwendet den Proxy". Es gibt auch Konstellationen, wo das Default Gateway des Servers nicht der Weg ins Internet ist. Ich kenn das so jetzt eher selten, aber hatte zuletzt einen Kunden mit dieser Situation. Die fast Lösung? Normalerweise fangen Admins jetzt immer an wie wild mit Netsh, Proxy Policy oder dgl. rumzubasteln nur um festzustellen das die Firewall trotzdem alles ablehnt und der Proxy nur die Hälfte zu sehen bekommt. Die ganze Lösung? Man mag es kaum glauben, aber etwas versteckt hat DirSync die Möglichkeit bekommen einen Proxy für die Kommunikation nach außen zu setzen. Wichtig: es ist ein unauthenticated Proxy - ansonsten bitte die entsprechenden Ausnahmen setzen. Über die von DirSync mitgelieferte Coexistence-Configuration PSSnapins ist es möglich die aktuellen Proxyeinstellungen des Users auf den Service anzuwenden. Dafür einfach: Add-PSSnapin Coexistence-Configuration Update-MSOLDirSyncNetworkProxySetting ausführen und schon funktioniert das Ganze auch mit Proxy. Was ich leider nicht testen konnte - SSL Interception. Also sollte jemand hier Erfahrungswerte beisteuern können, jederzeit gerne. LG Christoph
Cloud | DirSync | PowerShell | Office365
mehr