Alle Beiträge von Sebastian Hetzel

Passwortabfrage in Outlook nach Migration Exchange 2007 zu Exchange 2013

Heute bin ich bei einem Kunden auf ein Phänomen gestoßen, das mir ein paar graue Haare mehr beschert hat.
Nach Installation eines Exchange 2013 – CAS innerhalb einer bestehenden Exchange 2007 – Organisation zeigte sich den bereits auf 2013 migrierten Benutzern folgendes Fehlerbild:

  • Passwortabfrage erschien beim Starten von Outlook
  • Zugriff auf öffentliche Ordner nicht möglich (Fehlermeldung: Ein Clientvorgang ist fehlgeschlagen)
  • Kalenderfreigaben auf alten Exchange-Server konnten nicht geöffnet werden.

Um die Situation nachvollziehen zu können, muss man wissen, dass die öffentlichen Ordner  noch auf dem Exchange 2007 lagen und auf dem Exchange 2013 noch nicht eingerichtet worden sind.

Was ist passiert?

Seit Exchange 2013 gibt es keine Kommunikation via MAPI-Protokoll nativ mehr. Stattdessen kommt der gleiche Mechanismus zum Tragen, der bei Outlook Anywhere eingesetzt wird. Es werden MAPI-Pakete in HTTPS-Paketen gekapselt. Somit kommuniziert ein Exchange 2013 mit einem Exchange 2007 via „Outlook Anywhere“, sofern dies auf dem Exchange 2007 aktiviert worden ist.

Die Kommunikation kommt aber in diesem Fall nicht zustande, da die von den Servern unterstützen Authentifizierungsmethoden nicht übereinstimmen.

Abhilfe

Die Outlook Anywhere Authentifizierungsmethoden müssen auf Exchange 2013 und Exchange 2007 übereinstimmen.

Die Servereigenschaften unter Exchange 2013:

ex2013_outlookanywhere_auth

Die Servereigenschaften unter Exchange 2007:

ex2007_outlookanywhere_auth

Exchange Autodiscover

Exchange 2013

Autodiscover ist ein Mechanismus, der Clients ein XML-File auf einem Webserver zum Download hinterlegt, in welchem die Konfigurationsparameter für den Client aufgeführt sind. So ist eine manuelle Einrichtung von beispielsweise Outlook nicht mehr nötig.

Damit dies tadellos funktioniert, muss dieser Webservice innerhalb und außerhalb der Exchange-Organisation verfügbar gemacht werden. Erschwerend kommt dabei hinzu, dass Exchange dieses Service von Hause aus über eine gesicherte Verbindung zu Verfügung stellt. Vor der Installation sollte daher konzeptioniert werden, wie der Zugriff auf den Dienst realisiert werden soll.

Client-Seite

Um zu verstehen, wie das Autodiscover an die eigenen Bedürfnisse anzupassen ist, ist es meiner Meinung nach wichtig zu verstehen, was der Client (Outlook/Smartphone/etc.) abfragt, um an die Informationen zu gelangen.

Outlook fragt folgende Stellen in der nachfolgenden Reihenfolge ab. Das Verhalten ist hardkodiert und kann somit nicht geändert werden. Werden die gewünschten Informationen über eine der Quellen bezogen, werden die restlichen Quellen nicht mehr abgefragt.

  • SCP-Suche
  • HTTPS-Stammdomänenabfrage
  • HTTPS-AutoErmittlung-Domänenabfrage
  • Lokale XML-Datei
  • HTTP-Umleitungsmethode
  • SRV-Datensatzabfrage
  • Zwischengespeicherte URL im Outlook-Profil (neu für Outlook 2010 Version 14.0.7140.5001 und neuere Versionen)
  • Direkte Verbindung mit Office 365 (neu für Outlook 2016 Version 16.0.6741.2017 und neuere Versionen)

An dieser Stelle ist wichtig zu wissen, was sich hinter dem Begriff Domäne verbirgt:
Hier handelt es sich um die primäre Maildomäne, nicht etwa die AD-Domäne. Lauten die Mailadressen beispielsweise auf adresse@mail.de, dann ist mail.de die Domäne.

Verfügbarkeit anpassen

In der Regel ist hier kein Handlungsbedarf. Bei der Installation von Exchange werden innerhalb der AD zum einen der SRV-Record im DNS, zum anderen der SCP ins AD geschrieben.
Interessant wird es, wenn die Autodiscover-URL wegen Zertifkatsnamen etc. geändert werden soll. Sprich es soll nicht mehr der interne Servername abgefragt werden. Für diesen Fall kann über die Powershell die URL manipuliert werden.

Zur Abfrage der aktuellen Autodiscover-URL ist folgender Befehl vorgesehen:

Get-AutodiscoverVirtualDirectory | fl internalurl,externalurl

sowie

Get-ClientAccessServer | fl *InternalUri*

Um die URL’s zu setzen werden entsprechend folgende Befehle verwendet:

Set-ClientAccessServer -Identity "EX-CAS-01" -AutodiscoverServiceInternalURI "https://mail.mydomain.com/autodiscover/autodiscover.xml"

sowie

Set-AutodiscoverVirtualDirectory -ExternalUrl 'https://mail.mydomain.com/Autodiscover/Autodiscover.xml' -InternalUrl 'https://mail.mydomain.com/Autodiscover/Autodiscover.xml'

 

IPv6 deaktivieren

In manchen Szenarien möchte man gerne das neue IP-Protokoll deaktivieren. Dies kann der Fall sein, wenn die eingesetzten Router kein IPv6 unterstützen oder man sich einfach nicht mit dem Thema beschäftigen möchte.

Hier sei nochmals erwähnt, dass eine Deaktivierung von IPv6 unter Windows nur über die Registry von Microsoft supportet wird! Das Entfernen der Bindung von IPv6 an eine Netzwerkschnittstelle kann zu Problemen führen.

Deaktivierung W7 / Server 2008 (R2) / Vista

Microsoft hat für die Betriebssysteme

  • Windows 7
  • Server 2008
  • Server 2008 R2
  • Vista

eigene Fixits herausgebracht. Diese können hier heruntergeladen werden:

https://support.microsoft.com/de-de/kb/929852

Deaktivierung Server 2012 / W8

Wie im oben aufgeführten Supportartikel von Microsoft zu entnehmen ist, werden die IPv6-Komponenten mittels Registry-Einträgen deaktiviert. Da es für Server 2012 und Co keine Fixits gibt, setzen wir die Registry-Keys einfach per Powershell. Manuell geht es natürlich auch. Das System muss im Anschluss neugestartet werden.

PS> New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters -Name DisabledComponents -PropertyType DWord -Value 0xffffffff

Exchange: AD-Schema erweitern

Letztens bin ich bei einem Kunden auf folgende Fehlermeldung gestoßen. Scheinbar prüft das Setup des Exchange 2013 nicht mehr zwingend, ob das Schema für den Exchange aktualisiert werden muss, wenn bereits eine Exchange-Organisation besteht.

ex2013_schema_error

Abhilfe

Die Lösung des Problems ist relativ simpel. Auf einem Domänencontroller kann das Setup mit folgenden Parametern gestartet werden, um das Schema zu erweitern:

setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

Damit das Setup erfolgreich auf einem DC ausgeführt werden kann, muss zuvor das Windows Management Framework 3.0 installiert werden:

Installation von Exchange 2013

Exchange 2013

Voraussetzungen

Exchange sollte auf einem Memberserver innerhalb einer AD installiert werden. Installationen direkt auf einem DC werden von Microsoft nicht unterstützt, sind aber technisch möglich.

Hier eine kleine Checkliste für die Installation des Memberservers:

  • Betriebssystem ist mindestens Server 2008 R2
  • Hostname ist festgelegt worden (dieser kann nicht mehr geändert werden!)
  • Aktuelle Windows Updates sind eingespielt worden
  • Forrest-Level / Domain-Level = Windows Server 2003 oder höher

Benötigte Windows-Features instalieren

Am besten machen wir das, wie beim Exchange 2010 auch, mit der Powershell:

PS> Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

exch2013_install_01

Im Anschluss muss der Server neu gestartet werden!

ex2013_inst_features_reboot

Folgende Microsoft-Komponenten müssen ebenfalls heruntergeladen uns installiert werden:

ex2013_com_api_install

Im Anschluss lohnt es Windows Update noch mal auszuführen!

AD-Schema erweitern

Dazu muss auf dem Schemamaster die Installations-DVD von Exchange 2013 eingelegt werden.

ex2013_dvd

In der Administrator-CMD:

F:
setup /PrepareSchema /IAcceptExchangeServerLicenseTerms

ex2013_schema_prepare

Domäne vorbereiten

Zusätzlich muss die Domäne vorbereitet werden. „MYAD“ muss durch den NetBIOS-Name der Domäne ersetzt werden.

F:
setup /PrepareAD /OrganizationName:MYAD /IAcceptExchangeServerLicenseTerms

ex2013_orga_prepare

Start des Exchange-Setups

ex2013_setup_1

ex2013_setup_2

ex2013_setup_3

ex2013_setup_4

ex2013_setup_5

ex2013_setup_6

ex2013_setup_7

ex2013_setup_8

ex2013_setup_9

ex2013_setup_10

ex2013_setup_11

ex2013_setup_12

Updates für Exchange 2013

Ob ein Update erforderlich ist, kann über die Build-Number herausgefunden werden:

ex2013_build

Produktname Build Number Datum KB
Microsoft Exchange Server 2013 RTM 15.0.516.32 03.12.2012
Exchange Server 2013 Cumulative Update 1 (CU1) 15.0.620.29 02.04.2013 KB2816900
Exchange Server 2013 Cumulative Update 2 (CU2) 15.0.712.24 09.07.2013 KB2859928
Exchange Server 2013 Cumulative Update 3 (CU3) 15.0.775.38 25.11.2013 KB2892464
Exchange Server 2013 Service Pack 1 (SP1 aka CU4) 15.0.847.32 25.02.2014 KB2926248
Exchange Server 2013 Cumulative Update 5 (CU5) 15.0.913.22 27.05.2014 KB2936880
Exchange Server 2013 Cumulative Update 6 (CU6) 15.0.995.29 26.08.2014 KB2961810
Exchange Server 2013 Cumulative Update 7 (CU7) 15.0.1044.25 09.12.2014 KB2986485
Exchange Server 2013 Cumulative Update 8 (CU8) 15.0.1076.9 17.03.2015 KB3030080
Exchange Server 2013 Cumulative Update 9 (CU9) 15.0.1104.5 16.06.2015 KB3049849

> Quelle: http://social.technet.microsoft.com/wiki/contents/articles/15776.exchange-server-2013-and-cumulative-updates-cus-build-numbers.aspx

Smarthost festlegen

Dies kann unter dem Menüpunkt Narichtenfluss >> Sendeconnectors im Exchange Admin Center festgelegt werden:

ex2013_sendconnectors

Domänen festlegen

Menüpunkt: Nachrichtenfluss >> Akzeptierte Domänen

ex2013_domaenen

Adressrichtlinie definieren

Menüpunkt: Nachrichtenfluss >> E-Mail-Adressrichtlinie

ex2013_adressrichtlinien

Jetzt Windows 10 herunterladen!? – Nein, danke!

Microsoft Windows erinnert ab sofort täglich den Benutzer daran, dass er auf Windows 10 umsteigen möge. Irgendwann fängt es an zu nerven…

get_windows_10

Mit den nachfolgenden Schritten wird man die Windows 10 – Werbung wieder los.

Deinstallation von Update KB3035583

In den letzten Wochen hat Microsoft ein Windows-Update mit der Nummer KB3035583 herausgebracht und dieses zeitweise als wichtig markiert, so dass es automatisch installiert wurde. Dieses Update beinhaltet einen Windows 10 – Downloader, welcher auf sich wie oben geschildert aufmerksam macht.

Zur Deinstallation des Updates ruft man „Programme und Funktionen“ der Systemsteuerung auf. Dies geht am schnellsten über die Windows-Funktion „Ausführen“ (Tastenkombi [Win]+[R]) mit dem Befehl

appwiz.cpl

appwiz-cmd

In der erscheinenden Ansicht sind die auf dem System installierten Programme aufgelistet. Wir benötigen aber die Liste der installierten Updates. Daher schalten wir über den Link „Installierte Updates“ / „View installed updates“ die Ansicht um:

view_installed_updates

Nun suchen wir nach der KB-Nummer. Oben rechts bietet das Fenster eine Suchmaske an. Nach einiger Zeit wird in der Liste das Update aufgelistet und kann über Rechtsklick deinstalliert werden. Damit die Änderungen wirksam werden, muss der Rechner neugestartet werden.

search_update

Update ausblenden

Damit beim nächsten Durchlauf von Microsoft Update das unerwünschte Stück Software nicht erneut installiert wird, muss es „ausgeblendet“ werden. Dazu rufen wir Windows Update auf und lassen das System nach neuen Updates suchen. Im Anschluss an den Suchvorgang sollte mindestens 1 Update zur Installation angeboten werden. Über die Liste der zu installierenden Updates / Updateübersicht kann nun mittles Rechtsklick auf das unerwünschte Update ein Kontextmenü aufgerufen werden, welches die Funtkion „Update ausblenden“ preisgibt.

Updateeinstellungen prüfen

Damit das Update nicht erneut als wichtiges Update markiert und dann installiert wird, ist es außerdem ratsam folgende Einstellungen für Windows Update vorzunehmen:

update_einstellungen

ESXi-Server für Zuhause

Leider gibt es im Netz derzeit nicht viele Quellen, auf die man sich stützen kann, wenn man das Thema ESXi-Homeserver angehen möchte. In der Regeln sind ESXi-kompatible Systeme in der Anschaffung teuer, da die Hardware von Vmware zertifiziert werden muss, um auf die sogenannte HCL (Hardware Compatibitility List) gesetzt zu werden.

Ich habe mich auf die Suche gemacht nach einem System, dass folgende Kriterien erfüllt:

  • Installation von ESXi 5.x möglich
  • Festplatten im Hardware-Raid-Verbund
  • Mindestens 16 GB RAM
  • Preis unter 1500 Euro

Viele Systeme laufen ebenfalls mit Vmware ESXi, weil die verbauten Komponenten kompatibel zum Betriebssystem sind. Diese Systeme tauchen aber nicht auf der HCL auf. Diesen Weg kann man auf alle Fälle ebenfalls verfolgen.
Die Firma LS Computersysteme in Langenfeld ist ein Hardwarespezialist für Server und bietet in seinem Portfolio auch Systeme an, welche von den Komponenten her Vmware-tauglich sind, aber nicht auf der HCL auftauchen. Ist man sich nicht sicher, können die Vertriebsmitarbeiter um Rat gefragt werden. Im Vergleich zu einem zertifizierten Marken-System lassen sich so mehrere hundert Euro sparen.

In meiner Konfiguration habe ich einen anderen Weg eingeschlagen: Die Lösung heißt DELL PowerEdge T110ii. Dieses System ist von Hause aus auf der HCL gelistet und wohlmöglich das günstigste System mit offizieller Freigabe durch Vmware.
Aber vorsichtig, hier gibt es mehrere Konfigurationsvarianten, von der nur eine mit dem Betriebssystem harmoniert: Der Hypervisor lässt sich nur auf die Festplatten installieren, wenn der PERC H200 Raidcontroller verbaut wurde! Wurde der kleinere Bruder, PERC S200, verbaut, erkennt das Setup das Storagesystem nicht.

poweredge_t110ii_esxi

Kurzer Exkurs zum Raidcontroller der Marke PERC

In der Produkbezeichnung wird schon der Unterschied klar. H steht für Hardwareraid, S steht für Softwareraid. Sollte man sich für den H200 entscheiden, wird man relativ schnell nach Installation von ESXi feststellen, dass das System ziemlich zäh und träge läuft. Das System besitzt keine BBU und schaltet deshalb sämtliche Caches ab. Auch den Cache der Festplatten selbst.

Bedient man sich eines Tricks, kann die Policy des Controller manipuliert werden, die der Deaktivierung des Caches zu Grunde liegt:
DELL bietet eine Boot-CD zum Download an, den Open Manage Server Administrator (OMSA). Nach Starten der CD müssen folgende Befehle auf der Bash aubgesetzt werden, um die Caches wieder zum Leben zu erwecken:

# omconfig storage vdisk action=changepolicy controller=0 vdisk=0 diskcachepolicy=enabled

Um die richtigen ID’s in den Befehl einzusetzen, kann mit dem nachfolgenden Kommando ausgelesen werden, welche Controller-ID benötigt wird. Sollten mehrere Controller verbaut sein, wird dies interessant. In der Regel handelt sich bei einem einzigen Contoller um die ID 0:

# omreport storage controller

Gleiches gilt für die ID’s der vdisks. Außerdem kann mittels folgendem Befehl kontrolliert werden, ob die Policy geändert worden ist:

# omreport storage vdisk

In der Auflistung sollte nun der Wert „Cache Policy“ von „Not Applicable“ auf „Enabled“ umgesetzt worden sein.
Es muss nichts gespeichert werden. Die Policy ist sofort aktiv. Das System kann nun neugestartet werden, um den Hypervisor zu booten.

„Die Cloud“ oder „die klaut“?

Die Cloud kommt – immer mehr Dienste ziehen in die Cloud, immer mehr Softwarehersteller drängen in die Cloud. Das prominenteste Beipiel ist wohl Microsoft: Man betrachte Office 365 oder Azure.

Fangen wir doch damit an, uns einen groben Überblick über dieses Thema zu verschaffen.

Was ist die Cloud?

„Unter Cloud Computing (deutsch etwa Rechnen in der Wolke) versteht man das Speichern von Daten in einem entfernten Rechenzentrum, aber auch die Ausführung von Programmen, die nicht auf dem lokalen Rechner installiert sind, sondern eben in der (metaphorischen) Wolke (englisch cloud).“ — http://de.wikipedia.org/wiki/Cloud_Computing 2014/12/26 14:55

Man kann unterscheiden zwischen

  •     IaaS (Infrastructe as a Service)
  •     PaaS (Platform as a Service)
  •     SaaS (Software as a Service)

IaaS

Infrastruktur aus der Cloud. Das können virtuelle Rechner und Server sein, aber auch ganze IT-Landschaften, worauf Unternehmen Ihre Firmen-EDV betreiben. Bei diesem Konzept ist die eingesetzte Hardware hoch skalierbar und flexibel (z. B. auf Knopfdruck weitere Server anlegen), jedoch nicht unbedingt die darauf betriebene Software. Diese ist meistens nicht Bestandteil der Dienstleistung und der Mieter/Käufer administriert die Systeme vorwiegend selbst.

PaaS

Das System stellt dem Benutzer eine Schnittstelle zur Verfügung, in der er seine eigene Programmlogik in eine installierte Anwendung implementieren kann. Einflussnahme auf die Systeme selbst (in administrativier Hinsicht) besteht nicht. Das System administriert sich selbst, skaliert selbst, abhängig von der Nutzung. Das Konzept ist sehr interessant für Entwicklungsumgebungen.

SaaS

Dieses Konzept inkludiert die bereits vorher genannten „Ebenen“. Hier muss der Anwender gar nichts tun. Er bezieht eine Softwaredienstleitung aus der Cloud und kommt mit Entwicklungsthematiken oder infrastrukturellen Fragen nicht in Berührung.

Finanzieller Aspekt

Finanziell ist sie sehr attraktiv:

  •     Keine Anschaffungskosten für Hardware
  •     Hohe Flexibilität und Skalierbarkeit
  •     Update / Neuerungen inklusive

Einsatz für die Cloud

Welche Dienst machen in der Cloud Sinn?

  •     Mailgateway / Spamfilter
  •     Exchange
  •     Mailbox
  •     VoIP / Telefonanlage
  •     Sämtliche anderen Webservices

Was macht keinen Sinn

  •     Fileserver (Datenschutz)
  •     Document Management System (Datenschutz)

Windows-Update-Loop mit KB3033395

Beim dieswöchigem Patchday ist mir auf den Systemen mit Windows Server 2003 ein Update ganz besonders aufgefallen: Microsofts KB3033395 möchte sich nach erfolgreicher Installation und Reboot immer wieder installieren.

KB3033395

Ebenso eine Deinstallation des Updates und darauffolgende Installation bringen keine Abbhilfe, genauso wenig wie das Zurücksetzen des gesamten Windows Updates auf dem Client.

Bisher scheint es keinen Fix zu geben.

Nähere Infos zum Patch gibt auf folgenden Webseiten:

Update 13.03.2015:

Der Fehler scheint nur in Verbindung mit der Verteilung über einen WSUS aufzutreten.

Update 14.03.2015:

Ich habe gerade getestet, ob es einen Unterschied macht das Update direkt von Microsoft Update zu installieren: Macht es nicht! Der Loop tritt trotzdem auf – zumindest bietet der WSUS das Update immer wieder an.

Update 18.03.2015:

Microsoft hat wohl eine neue Revision des Updates herausgebracht. Heute habe ich den Patch auf diversen Systemen installiert, ohne dass der Loop auftrat.