Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

30Jun/160

Exchange 2010: Viele merkwürdige Fehler und eine fast noch merkwürdigere Lösung

Auf einem produktiven Exchange 2010 SP3 mit aktuellem Patchstand begegnete mir heute folgendes Problem: Der Mailserver war weder über Outlook noch über OWA erreichbar und wenn man sich per RDP angemeldet hat, dann war nahezu nichts möglich, jede Aktion führte zu einem sich ewig drehenden Sanduhr-Symbol. Keines der Systemsteuerungswerkzeuge oder auch nur die Netzwerkwerk-Adapter-Verwaltung ließen sich öffnen.

Um zunächst erst mal mit dem Server arbeiten zu können, hatte ich ihn im abgesicherten Modus gestartet. Da hier aber auch sehr viele Werkzeuge nicht funktionieren, habe ich alle Exchange-Dienste deaktiviert und die Maschine neugestartet. Jetzt konnte man erst mal wieder arbeiten und mit der Fehlersuche beginnen.

Zunächst hatte ich mit ESEUTIL die Datenbank-Files geprüft, hier war aber alles in Ordnung. Netzwerk, DNS und co. sowieso, DC war auch erreichbar, auch Kerberos-Auflösungen waren kein Problem. Da ich am Vorabend das aktuellste Update Rollup 14 eingespielt hatte, hatte ich dieses im Verdacht und hab es wieder deinstalliert – ohne Erfolg. Der Server reagierte wieder so wie vorher.

Im Eventlog war mir vor allem dieser Fehler aufgefallen:

Exch2010_1

(Quelle: MSExchange ADAccess | Ereignis-ID: 2114 | Aufgabenkategorie Topologie)

Außerdem noch dieser Fehler:

Exch2010_2n

(Quelle: MSExchange ADAccess | Ereignis-ID: 2102 | Aufgabenkategorie Topologie)

Dort heisst es: “Keine Antwort von allen verwendeten Domänencontrollerservern”. Dies war merkwürdig, weil sämtliche Arten der von mir getesteten Kommunikation mit dem DC funktionierten tadellos, zur Sicherheit hatte ich noch ein dcdiag gegen den DC laufen lassen – ohne Auffälligkeiten. Zur Sicherheit hatte ich noch das Computerkonto sowie den Secure Channel zurückgesetzt die Mitgliedschaft des Computerkontos in den notwendigen Exchange-Gruppen im AD geprüft.

Symptomatisch war, dass sich der Dienst “Microsoft Exchange Active Directory-Topologie” und auch “Microsoft Exchange-Diensthost” relativ problemlos (wenn auch nur mit längerer Wartezeit) starten ließen, aber die “Microsoft Exchange-Systemaufsicht” ließ sich nicht starten!

Nach etwas Suche im Internet fand ich diverse Hinweise. Der erwarte war das Thema IPv6 – tatsächlich hatte mein Vorgänger dies am Exchange Server abgeschaltet. Also das Häckchen wieder rein:

Exch2010_3

Leider brachte dies – auch nach einem Neustart nichts.

Ein weiterer Hinweis der sich fand, schien mir etwas abwegig, aber da ich kurz vor dem Restore des gesamten Servers stand, habe ich es drauf ankommen lassen und das Computerkonto des Exchange-Servers in die Gruppe der Domänen-Admins aufgenommen. Und tatsächlich, nach einem Neustart des Servers kamen alle Dienste hoch. Damit war mein Kernproblem zwar gelöst, aber ich war mir sicher, die eigentliche Ursache nicht gefunden zu haben, denn es ist IMHO keine Bedingung für Exchange, dass der Server DomAdmin ist. Nach längeren Recherchen fand ich dann den “Übeltäter”:

Eine GPO hatte die Berechtigung für “Manage auditing and security log” (“Verwalten von Überwachungs- und Sicherheitsprotokollen”) auf einen zu kleinen Benutzerkreis festgelegt.

Exch2010_4

Laut diesem Artikel muss hier auch die Gruppe der Exchange-Server mit eingetragen werden – und zwar für die GPO die auf die DCs zielt!

Das war also das recht kleine Problem mit riesiger Auswirkung!

Jeden Tag fiebere ich nun der endgültigen Umstellung auf Office 365 entgegen – dann gehören derartige Probleme wohl der Vergangenheit an.

30Jun/160

Microsoft Technical Summit – auch 2016 wieder in Darmstadt

Nur als kurze Info:

Der Termin sowie der Ort für den kommenden Microsoft Technical Summit stehen fest - es geht wieder nach Darmstadt, und zwar vom 6. bis 8. Dezember!

msts16

Weitere Details siehe hier: https://www.microsoft.com/germany/technical-summit/default.aspx - dort müsste demnächst auch die Agenda veröffentlicht werden.

 

24Jun/160

Windows Server / Client: Alle geplanten Tasks per PowerShell auslesen

Insbesondere auf Servern kann es schnell vorkommen, dass hier sehr viele Gepante Tasks ("Aufgaben") vorhanden sind, die aber über viele Ordner im Taskplaner verteilt sind:

TaskPlaner

Wenn man nun einen bestimmten Task sucht oder einfach wissen möchte, was so an Aufgaben alles geplant ist, dann ist die GUI hier leider keine große Hilfe. Aber mit der PowerShell bekommt man schnell das Gewünscht:

1
Get-ScheduledTask | Select URI,@{n="LastRun";e={($_ | Get-ScheduledTaskInfo).LastRunTime}} | Sort-Object LastRun

TaskPlaner2

Viel Spaß damit!

23Jun/160

Hyper-V-Server / Windows Server Core: Treiber via PowerShell installieren

Wer einen Windows Server 2012 R2 als Core-Server oder den kostenfreien Hyper-V-Server 2012 R2 einsetzt, dem könnte folgendes Problem begegnen: Auf dem Server selber gibt es bekanntlich keine GUI und demnach auch keinen Gerätemanager. Und seit 2012 R2 lässt sich dieser auch nicht remote von einem grafischen Server aus ansprechen!

Was nun also tun, wenn man Treiber installieren/aktualisieren/entfernen will? Dazu möchte ich hier einige Kommandos als Hilfestellung zusammentragen:

 

Installation aller Treiber des aktuellen Verzeichnisses in das Treiber-Repository:

Get-ChildItem -Recurse -Filter *.inf | Select-Object FullName | ForEach-Object {pnputil -a $_.FullName}

Installation eines bestimmten Treibers:

pnputil.exe -i -a C:\Pfad\zum\Treiber.inf

(ACHTUNG: Installiert diesen Treiber für alle "passenden" Geräte!)

Auflisten aller Treiber im Repository (3rd Party):

pnputil.exe -e

Entfernen eines Treibers aus dem Repository:

pnputil.exe -d oemX.inf (Name der INF-Datei über pnputil -e)

Entfernen aller Treiber aus dem Repository:

1..40 | ForEach-Object {pnputil.exe -d "oem$_.inf"} (Die Zahl 40 muss ausgetauscht werden durch die höchste Zahl aus pnputil -e)

Ermitteln der Hardware-ID der Geräte einer bestimmten Geräteklasse (hier: Netzwerkkarten)

devcon.exe listclass net

Anzeigen des von einem Gerät benutzten Treibers:

devcon.exe driverfiles "@PCI\VEN_8086&DEV_10D3&SUBSYS_040D15D9&REV_00\4&60B4255&0&00E4"

Installation eines bestimmten Treibers für ein bestimmtes Gerät:

devcon.exe /r install C:\Pfad\zum\Treiber.inf "@PCI\VEN_8086&DEV_10D3&SUBSYS_040D15D9&REV_00\4&60B4255&0&00E4"

Entfernen eines konkreten Gerätes (nicht nur der Treiber!):

devcon.exe /r remove "@PCI\VEN_8086&DEV_10D3&SUBSYS_040D15D9&REV_00\4&60B4255&0&00E4"

Nach neuen Geräten suchen:

devcon.exe rescan

 

Für einige Varianten ist DevCon.exe nötig. Siehe dazu hier:

https://msdn.microsoft.com/de-de/library/windows/hardware/ff544707(v=vs.85).aspx

Tipparchiv

Der Artikel wird künftig weiter ergänzt...

20Jun/160

SCCM 2012 / 2012 R2 / 1511: HowTo Video zum Thema Endpoint Protection

Auf meinem YouTube-Kanal findet ihr seit heute ein Video zum Thema System Center Endpoint Protection. Viel Spaß beim Anschauen!

SCCM-Endpoint_Protection_Neu

https://youtu.be/-7sCHWDJsaE

7Jun/160

Hyper-V: PowerShell-Skript um nicht benutzte bzw. verwaiste VHD / VHDX Dateien zu finden

Auf einem Hyper-V System sammeln sich über die Jahre einige virtuelle Festplatten-Dateien im VHD- bzw. VHDX-Format an. Aber werden diese wirklich noch alle gebraucht? Das ist häufig schwer zu sagen, da insbesondere durch das Löschen von VMs nur deren Beschreibungs-Dateien, nicht aber die Festplatten gelöscht werden. Ähnliches kann passieren, wenn man die Replikation einer VM beendet.

Um nun diejenigen VHDs, die von keiner VM mehr genutzt werden, zu finden, habe ich ein Skript geschrieben. Dieses berücksichtigt auch, dass sich mehrere VHD/VHDX Dateien in einer Differenzierungskette befinden könnten.

Das Skript sowie eine Beschreibung findet ihr hier:

https://gallery.technet.microsoft.com/scriptcenter/Get-AbandonedVHDs-V1-to-8bfb28d9

Dem Skript kann neben einem oder mehreren Suchordnern auch u.a. eine Option übergeben werden, die direkt die nicht benötigten Dateien löscht. Das ist aber nicht ganz ungefährlich, ggf. haben die VHDs ja eine andere Funktion und sind gar nicht für Hyper-V. Denkbar wäre z.B., dass ein iSCSI-Software-Target im Einsatz ist, oder aber auch die Windows Server Sicherung.

script