Stichwort Suche

Monat: Dezember 2017

VMware vSphere Client Authentication Plugin startet nicht

Das Plugin ist auf dem Computer installiert, aber die Option ” Windows-Sitzungsauthentifizierung verwenden” ist ausgegraut.

Lösung:

Das vCenter Root CA auf den lokalen Client importieren + installieren + vertrauen ( Achtung Firefox nutzt eigenen Zertifikatsspeicher 🙂 )

 

Sollte es danach immernoch nicht funktionieren, überprüfen ob auf em lokalen Client der “vmware cip message proxy service” Dienst gestartet ist.

Falls nicht einmal starten..

VMware vSphere VM on dead host

Ist eine vSphere Hypervisor nicht mehr erreichbar und das vCenter geht davon aus, das auf diesem Host die VM liegt ist es zur schnellen abhilfe möglich die VM umzuregistrieren:

1) SSH auf Host einen aktiven Host auf dem die VM gehostet werden soll

2) In Ordner /vmfs/volumes wechseln Inhalt anzeigen lassen ( ls ) – Achtung die Namen können sich verschieben, sodass diese nicht zu den ID’s davor passen

3) urspüngliche Source von dieser VM lokalisieren ( über vsphere Console – VM Übersicht – Speicher ) / Oder von Punkt 2) die Volumes durchsuchen

4) VM umregistrieren

vim-cmd solo/registervm /vmfs/volumes/53d37115-673ddBeispielpfad/VMName/VMNAME.vmx

5) Überprüfen ob erfolgreich

vim-cmd vmsvc/getallvms

Exchange 2010 to 2016 Outlook nach Move getrennt

Mir ist jetzt schon seit mehreren Exchange 2016 Versionen ( CU 4 bis CU 7 ) während der Migration passiert, dass nach einem erfolgreichem Mailbox Move  Outlook nach dem neustart ( Ihr Exchange Administrator hat … 🙂 ) sich nicht zum Exchange 2016 verbindet.

Prüft man den Client mit dem Autokonfiguration Test passiert folgendes:

Die Verbindung zum SCP scheitert…

Ein XML File gibt es dadurch auch nicht…

 

Lösung:

Warten, oder im IIS den “MSExchangeAutodiscoverAppPool”  rechtsklick recyceln ( Wiederverwenden )

Danach klappts auch wieder mit dem Autodiscover und der Outlook Client kann sich verbinden.

Autodiscover Service Connection Point / Exchange SCP

Der Service Connection Point ist ein Eintrag im Active Directory, der von einem Outlook Client genutzt werden kann, um eine Quelle zu finden, über die er das “Autodiscover.xml” File beschaffen kann.

Anschauen kann man ihn sich unter AD Standorte und Dienste ( Ansicht > Dienstknoten anzeigen aktivieren ) unter “Services/Microsoft Exchange/EXOrga/Administrative Groups/Exchange Administrative Group/Servers/EXServer/Protocols/Autodiscover/EXServer

Oder über die Powershell:

Get-ClientAccessServer -Identity Server | fl

Unter dem Punkt “AutoDiscoverServiceInternalUri”.

 

Möchten man den SCP abändern lässt sich dies über die Powershell ausführen.

Set-ClientAccessServer -Identity Server -AutoDiscoverServiceInternalUri https://autodiscover.domain.com/Autodiscover/Autodiscover.xm

Wichtig:

  • Wird der Eintrag angepasst, muss sichergestellt sein, dass der FQDN auf dem Zertifikat, welches auf dem Exchange Server hinterlegt ist, enthalten ist. Sonst bekommen die Outlook Clients beim starten eine Zertifikatswarnung.  Das heißt wenn der Eintrag zum Beispiel auf “https://autodiscover.rehberger.de/Autodiscover/Autodiscover.xml” abgeändert wird, MUSS auf der Eintrag “autodiscover.rehberger.de” auf dem Zertifikat vorhanden sein.
  • Der SCP kann einer Active Directory Site zugwiesen werden. Damit kann in größeren Firmen mit mehreren Standorten und Exchange Servern pro Standort gesteuert werden, welchen SCP der Client nutzt.
  • Nachdem der AutodiscoverServiceInternalUri angepasst wurde muss der IIS neugestartet werden und die Domänen Controller müssen repliziert werden.

 

Autodiscover / Outlook Autodiscover / Outlook Postfach Einrichtung

Autodiscover ist ein Mechanismus, der u.a. von Outlook genutzt wird, um ein Outlook Profil so einzurichten, das dieses mit dem Exchange Postfach verbunden ist.

Mithilfe von Autodiscover bezieht der Client ( von einem CAS Server ) das “Autodisocover.xml” File, in dem sich für ihn alle wichtigen Informationen der Exchange Anbindung befinden.

In dem “Autodiscover.xml” ist enthalten:

  • Der Benutzer Anzeige Name
  • Verbindungseinstellungen für interne und externe Verbindungen
  • Location der Benutzer Mailbox ( der Server der gerade die Aktive Datenbank hostet )
  • URLs für Free/Busy, OAB, Unified Messaging
  • Outlook Anywhere Einstellungen

 

Zusammen gefasst nutzt Outlook Autodiscover für:

  • Outlook Profil einzurichten oder Outlook Profil zu updaten
  • Regelmäßige überprüfung der Web Service URLs
  • Änderungen der Netzwerkverbindungen

 

Um das “Autodiscover.xml” File zu erhalten prüft Outlook drei Möglichkeiten, welche in folgender Reihenfolge abgefragt werden:

  1. Outlook sucht im Active Directory nach einem SCP ( Service Connection Point ) gelingt dies nicht geht es über zu Punkt zwei.
  2. Outlook versucht “https://domain.com/Autodiscover/Autodiscover.xml zu erreichen, gelingt dies nicht geht es über zu Punkt drei.
  3. Outlook versucht “https://autodiscover.domain.com/Autodiscover/Autodiscover.xml” zu erreichen
  4. Führt dies nicht zum erfolg wird Punkt 2. und 3. wieder mit HTTP redirect probiert.
  5. Als letztes probiert Outlook es über SRV Records

Für die Anfragen aus Punkt 2. und 3. nutzt Outlook immer die Domänen Endung von der SMTP Adresse ( in dem Beispiel oben wäre die Email Adresse also “max.mustermann@domain.com” )

Der SCP befindet sich im Active Directory. Erstellt wird er bei der Exchange Server installation. Es gibt pro CAS Server einen SCP. Per default ist dort der FQDN des Servers hinterlegt.

Mehr zum SCP befindet sich hier: https://deer-it.de/autodiscover-service-connection-point-exchange-scp/

 

Ausschnitt einer Ersteinrichtung eines Outlook Profils:

 

In diesem Beispiel ist der mitgeteilte SCP Endpunkt Server nicht erreichbar:

Client hat den SCP erhalten und löst den Namen auf, um sich mit ihm zu verbinden.

Er erhält keine antworten auf seine Anfragen..

Der Outlook Client schwenkt um und versucht es über eine “autodiscover.domain.com” oder SRV Record abfrage…

 

In diesem Beispiel ist der mitgeteilte SCP Endpunkt Server erreichbar:

Outlook verbindet sich dort hin und fordert das “Autodiscover.xml” File an.

 

Damit ist das Outlook Postfach eingerichtet.

Immer wenn Outlook gestartet wird frägt es erneut das “Autodiscover.xml” File an, um zu überprüfen, ob noch alle Einstellungen korrekt sind.

 

RPC/TCP – RPC/HTTP – Outlook Anywhere – MAPI/HTTP – Unterschied

Die einzelnen Transportprotkolle vereinfach dargestellt:

 

Jede Outlook Verbindung benutzt MAPI. MAPI-Aufrufe basieren immer auf Remoteprozeduraufrufen (RPC). RPC wird einfach genutzt um MAPI für die Kommunkation zu verpacken.

– RPC/TCP ist nur für die interne Kommunikation. Unterstütze Version Exchange 2010, 2007 und 2010.

– RPC/HTTP benutzt HTTP für die MAPI Kommunikation. Externe Kommunikation ist unterstüzt. Unterstütze Versionen sind Exchange 2016, 2013, 2010, 2007, 2003.

Exchange 2013 direkt nutzt RPC/HTTP – ( RPC/TCP ist bei Exchange 2013 nicht verfügbar )

– MAPI/HTTP wurde mit Exchange 2013 SP1 CU4 eingeführt. Dadurch wird MAPI nur in HTTP verpackt. ( Muss in der Organisation aktiviert werden )

Im Bild wird bei dem User unten der Outlook Zugriff über das interne Netzwerk durchgeführt.

Oben bei dem User wird über das Internet zugegriffen.

Client Domänen Join

Jeder tut es, doch was genau im Hintergrund bei einem Domänen Join passiert wissen wenige.

Es beginnt alles mit dem klick auf “OK”.

Nach dem Klick auf OK startet der Client eine DNS Abfrage:

 

Er frägt den DNS Server ( in dem Fall der Domäne Controller ) nach einem SRV Eintrag : “_ldap._tcp.dc._msdcs.rehberger.local” ab.

Der DNS Server antwortet mit: “jrdc01.rehberger.local”. So weiß der Client, an wen er sich wenden muss.

Da der Client nun einen Namen kennt, aber zu dem Namen keine IP Adresse macht er natürlich eine DNS Abfrage für den Server “jrdc01.rehberger.local”

Als antwort erhält er die IP Adresse “172.16.20.2” zurück

Ausschnit CLDAP Abfrage:

 

Nach der eingabe der Admin Credentials geht es weiter mit der Authentifizierung und LDAP abfragen:

LDAP Abfrage:

 

Mit dem BinRequest wird der Domänen join initiert und abgeschlossen:

 

 

Bind erfolgreich 🙂 :

DNS Abfrage für Kerberos:

 

Abfrage der Uhrzeit mittels NTP Dienst:

 

So sieht das ganze aus sicht der Firewall aus :-):

 

Uhrzeit abfrage:

 

Nach dem Neustart ( ohne Anmeldung ) passiert folgendes:

Durch die beim Domänen Join ausgeführten Netlogon abfrage, weiß der Client bei welcher Active Directory Site er angehörig ist. Diese speichert er in der Registry unter:

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters

Daher wendet er sich bei der Anmeldung ( in diesem Fall hier “default-first-site-Name” – ich hab den Site Namen noch nicht angepasst 😉 ) an diese Site.

Gruppenrichtlinien Abfrage:

KMS Abfrage wird ausgeführt für die Windows aktivierung. Da bei mir kein KMS installiert ist funktioniert dies nicht.

Client aktuallisert seinen DNS Eintrag:

« Vorherige Seite