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

28Sep/160

Windows Server 2016 und System Center 2016 Launch

Nur als kurze “Randnotiz”: Microsoft hat den Windows Server 2016 auf der Ignite in Atlanta vor nicht ganz 2 Tagen gelauncht. Den Blog-Artikel des Windows Server Teams findet ihr hier:

https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-windows-server-2016

Leider stehen die Bits noch nicht zum Download zur Verfügung, auch nicht in der MSDN. Allerdings kann man die Evaluation-Version als ISO oder VHD herunterladen, siehe hier:

https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2016

14445094_10154021146281636_2895277330281932190_o

Außerdem wurde am selben Tag das System Center 2016 gelauncht. Infos siehe hier:

https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-system-center-2016-and-new-services-for-operations-management-suite/

Die Evaluierungsversion gibt es hier:

https://www.microsoft.com/de-de/evalcenter/evaluate-system-center-2016

 

Viel Spaß mit den neuen Spielsachen!

16Jul/160

Release Dates für Windows Server 2016 und System Center 2016 stehen fest!

Da ich diese Woche unterwegs war kommt es etwas “verspätet”: Microsoft hat das Releasedate für Windows Server 2016 und System Center 2016 bekannt gegeben. Das Microsoft Windows Server Team schreibt auf seinem Blog:

We are excited to announce the official launch of Windows Server 2016 will be at the Ignite conference this Fall.

Die Ignite-Konferenz (quasi der Nachfolger der TechEd) findet Ende September (26.-30.09.) in Atlanta statt. Zeitgleich wird also der Release stattfinden – wir dürfen uns also freuen!

Gleichzeitig schreibt das MS Team, dass die aktuelle Technical Preview 5 gleichzeitig die letzte ist und diese auch bereits feature-complete ist, also alle künftigen Funktionen enthält.

Der Download der TP5 kann hier erfolgen:

https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

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.

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...

16Mai/160

Windows Server: HowTo Video zum Aufbau eines Clusters für Hyper-V

In einem weiteren YouTube-Video zeige ich euch, wie ihr einen Hyper-V Cluster mit dem Windows Server 2012 R2 oder 2016 aufbauen könnt. Das ist leichter als man denkt! Viel Spaß beim Anschauen.

Hyper-V-Cluster_Deckblatt

https://youtu.be/4bCeqfhoW0c

27Apr/160

Windows Server 2016 und System Center: Technical Preview 5 ist verfügbar

Seit etwa einer Stunde sind die Technical Preview (TP5) vom Windows Server 2016 sowie von System Center in der MSDN und im Evaluation Center verfügbar:

tp5_1

tp5_12

https://www.microsoft.com/de-de/evalcenter/evaluate-windows-server-technical-preview

Was neu ist im System Center TP5 lässt sich in diesem Blog-Artikel vom Engineering-Team nachlesen. Zum Server 2016 gibt es eine solche Übersicht scheinbar noch nicht… Viel Spaß beim Ausprobieren!

25Apr/160

Windows Server 2016: YouTube-Videos zum Aufbau und zur Administration einer Active Directory Domäne

Ich habe drei Videos rund um das Thema Active Directory erstellt und bei YouTube veröffentlicht.

Im ersten Video geht es um die Installation von Active Directory.

Das zweite Video behandelt die Verwaltung von Benutzern, Gruppen, Computern und OUs.

Im dritten Video zeige ich den Umgang mit Gruppenrichtlinien (GPOs).

Viel Spaß beim Ansehen!

Hier geht es zur gesamten AD-Playlist:

https://www.youtube.com/playlist?list=PLPK8RW8p4Ok9mJbpRzb0bq_OL7mfMm5hg

9Jun/150

Windows Server Technical Preview 2 (Build 10074) – Erster Eindruck

Seit einigen Tagen schon ist die Technical Preview 2 des kommenden Windows Server (aka “vNext”) in Technet und MSDN verfügbar. (Ich hatte in einem meiner letzten Artikel darüber berichtet) Leider bin ich erst heute dazu gekommen, mir das Ganze mal anzusehen.

Schon bei der Installation fällt auf, dass Microsoft immer mehr in Richtung No-GUI-Server tut:

TechPreview2_0

Der Setup-Assistent bietet 2 Versionen an. Einmal “Windows Server Technical Preview 2” und einmal “Windows Server Technical Preview 2”. Die erste Version ist der eine Server Core Installation, komplett ohne grafische Werkzeuge. Bei der zweiten Version bekommt man immerhin ein paar grafische Werkzeuge (z.B. den Servermanager), aber nicht die reguläre Shell (mit Desktop, Startmenü und co.) und auch keinen Explorer (da dieser ja auch durch die Shell gestellt würde).

Entscheidet man sich für die erste Version, so sieht es nach der Installation so aus:

TechPreview2_00

TechPreview2_01

TechPreview2_02

Selbst das “STRG-ALT-ENT” wird nun also in einer Konsole präsentiert!

 

Wenn man sich für die zweite Installations-Option (“with local admin tools”) entscheidet, dann schaut es nach der Installation so aus:

TechPreview2_1

TechPreview2_2

Hier hat man also immerhin einen grafischen Login und eben den Servermanager. Über diesen oder über die PowerShell lässt sich nun auch die grafische Oberfläche nachinstallieren:

TechPreview2_3

Der neue Windows Server bringt noch eine neue Rolle mit, die in der bisherigen Preview nicht enthalten war:

TechPreview2_5

Bei der neuen Rolle handelt es sich um den “Host Guardian Service”, welcher wohl dem Schutz von Virtuellen Maschinen dienen soll.

Weiterhin ist mir aufgefallen, dass es neue AD Funktionsebenen gibt:

TechPreview2_6

Mal sehen was ich noch so finde – ich bleibe auf jeden Fall dran!

7Apr/150

Wie ein guter Domänen-Name aussieht – und wie nicht.

Auf den ersten Blick klingt das für viele sicher nach einer trivialen Frage: “Wie soll die neue AD Domäne denn heißen?” – aber so trivial ist diese Frage gar nicht.

Zunächst einmal muss man sich natürlich an die Vorgaben halten:

  • Der volle Domänenname (“Fully Qualified Domain Name, FQDN”) darf maximal 255 Zeichen lang sein und darf dabei aus Kleinbuchstaben, Großbuchstaben, Zahlen und dem “-”-Zeichen bestehen. Pro Label sind 63 Zeichen zulässig.
  • Der NetBIOS Name der Domäne ist auf 15 Zeichen beschränkt sowie auf Unicode-Zeichen und ein paar wenige Sonderzeichen

Ein AD Domänen-Name ist immer auch ein DNS-Name. Ein Domänen-Name besteht daher in der Regel aus einem oder mehreren Präfixen und einem Suffix, nach dem Aufbau-Prinzip

Präfix1.Präfix2.Suffix

Nun findet man heute sehr viele Domänen-Name nach dem Aufbau “Firma.local”, “.site”, “.lan” und so weiter. Die Wahl dieses Namens ist in der Regel auf die frühere Empfehlung, als Suffix keine öffentlichen Internet-Toplevel-Domänen wie “.com”, “.net” oder “.de” zu verwenden, da es sonst zu dem Problem kommt, dass man eine gesplittete DNS-Verwaltung benötigt oder aus dem internen Netz heraus eine Webseite nicht erreichen kann, wenn diese aus dem selben Prä- und Suffix besteht.

Diese Empfehlung hat heute keine Gültigkeit mehr!

Erstens werden auch diese “selbsterdachten” Suffixe mittlerweile von den Anbietern als Toplevel-Domänen verkauft. Das von einem selbst verwendete “FIRMA.LOCAL” könnte also zeitnah Eigentum einer anderen Firma werden! Und zweitens gibt es in gewissen Szenarien ganz klare Vorgaben, die die Verwendung dieser selbsterdachten Suffixe verbieten. Eines davon ist, dass keiner der großen SSL-Zertifikat-Anbieter Zertifikate für derartige Domänen- oder Hostnamen mehr ausstellt! (Vergleich dazu auch: https://www.cabforum.org/Guidance-Deprecated-Internal-Names.pdf)

Also, wir halten zunächst fest: “.site”, “.local” oder ähnlich sind keine guten Suffixe! Besser ist es, offizielle TLD-Suffice wie “.com”, “.net” oder “.de” zu verwenden.

Aber was ist dann mit dem oder den Präfix(en)?

Wie wäre es, wenn man nun als “Firma Foo”, die “www.foo.com” als Webseite verwendet, “foo.com” als internen Domänennamen wählt? Das kann (besser: wird) zu Problemen führen. Hierzu ein kleines Beispiel:

Wenn ein Benutzer sich an einer Workstation innerhalb einer Domäne anmeldet, dann ist hierbei der Name (z.T. auch nur der NetBIOS-Name) der Domäne angegeben. Der Computer muss aber einen Domänencontroller kontaktieren können. Daher wird der Domänen-Name in den Namen eines DCs und dieser wiederum in eine IP-Adresse eines DCs übersetzt. Also, aus “foo.com” wird dann die IP eines DCs, hinter “foo.com” verbirgt sich ebenso die interne DNS-Zone.

Und was passiert, wenn nun jemand in dieser Firma “foo.com” in seinen Browser eingibt? Seine Browser würde versuchen, einen DC per HTTP anzusprechen, was in der Regel scheitert, weil ein DC kein Webserver ist!

Nun gibt es für den (ersten) Präfix zwei Optionen:

  • Man registriert eigens für diesen Zweck eine öffentliche Domäne, die aber nicht öffentlich sondern nur für die interne AD Domäne genutzt wird
  • Man nutzt eine Subdomäne einer bereits existierenden Domäne, die man auch öffentlich verwendet, im Idealfall die, die auch für die Webseite genutzt wird.

Wenn also “Firma Foo” die Domäne “foo.com” als Domäne für ihre Webseite nutzt, dann müsste der Name der obersten (ersten) interne AD-Domäne ABC.foo.com heissen. Dabei sollte “ABC” ein möglichst kurzes Wort sein, um die FQDN aller kommenden AD-Objekte nicht unnötig lang zu machen. Eine Option wäre z.B. “AD.FOO.COM”.

Damit nun bei der Anmeldung nicht “AD\User” sondern “FOO\User” genutzt wird, muss man einfach bei der Installation des ersten (!) Domänencontrollers der Domäne als NetBIOS-Namen anstatt des vorgeschlagenen “AD” das Wort “FOO” verwenden. (Achtung: Das nachträgliche Ändern des NetBIOS-Namen ist nicht trivial!)

Die Verwendung eines solchen DNS- und Domänen-Namens hat viele Vorteile:

  • Es muss nur ein einziger Domänen-Name (auf oberster Ebene) genutzt und verwaltet werden
  • Eine Trennung zwischen intern und extern ist problemlos möglich
  • Jeder interne Domänen- und Hostname ist weltweit einmalig (wer kann das bei “SERVER1.corp.local” schon behaupten?)
  • Für Zertifikate, E-Mail und co., wo naturgemäß externe Domänen nötig sind, ist bereits alles passend
  • Eine Anmeldung an den Systemen des Unternehmens kann mit der (öffentlichen) E-Mail-Adresse der Benutzer erfolgen. Niemand muss sich neben seiner Mail-Adresse noch einen (u.U. komplizierten) Benutzernamen merken.

Als Referenz und zum Weiterlesen empfehle ich folgende Links:

16Mrz/152

SCCM + WSUS + SCUP: Updates für 3rd-Party-Anwendungen mit Hilfe des Update Publishers über SCCM verteilen

Mit Hilfe des System Center Configuration Manager 2012 / 2012 R2 ist es sehr einfach möglich, Windows- und Microsoft-Updates an die Clients und Server des eigenen Netzwerkes zu verteilen. Im Hintergrund arbeitet hierzu der bekannte WSUS-Dienst, welcher wiederum mit Microsoft kommuniziert, um die Updates von dort zu beziehen.

Wäre es nicht auch gut, wenn man auf ähnliche Weise auch Anwendungen von anderen Herstellern patchen könnte? JA! Und man kann!

Das einzige was man neben WSUS und dem SCCM braucht, ist der System Center Update Publisher, kurz SCUP. Mit diesem kann man Updates anderer Hersteller aus “externen Katalogen” beziehen. Und das beste: SCUP ist kostenlos!

Im Folgenden möchte ich die Installation und Einrichtung von SCUP zeigen. Ausgangslage ist ein installierter SCCM mit einer einzigen Primary Site (stand-alone), einem installierten WSUS und einem darauf laufenden Software Update Point (SUP).

Installation SCUP

Als erstes muss SCUP heruntergeladen werden. Dies geht über diese Quellen:

https://technet.microsoft.com/de-de/systemcenter/bb741049.aspx

bzw.

https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11940

Nach dem Download kann die Installation durchgeführt werden, welche jedoch Admin-Rechte benötigt:

scup2 scup3 scup4

Wenn es sich bei dem WSUS-Server um einen Windows Server 2008 R2 oder älter handelt, dan ist die Installation eines Patches nötig, der während des SCUP-Setup angeboten wird:

 scup5

Auf einem Windows Server 2012 / 2012 R2 ist dieses Patch nicht nötig – hier läuft WSUS 4.0!

scup6

Konfiguration WSUS-Berechtigungen

Um nun überhaupt Updates via SCUP auf dem WSUS veröffentlichen zu können, ist noch etwas Vorarbeit nötig. Diese Vorgänge sind etwas genauer hier dokumentiert (dies betrifft idR nur den Windows Server 2012 / 2012 R2):

https://technet.microsoft.com/en-us/library/hh134747.aspx#PublishToServer2012

Folgende Schritte sind im Wesentlichen nötig:

Regedit.exe, dort bis HKEY_CLASSES_ROOT\AppID\{8F5D3447-9CCE-455C-BAEF-55D42420143B} durchhangeln und dann den Eigentümer von diesem Pfad ändern sowie für “SYSTEM” und die “Administratoren” den Vollzugriff vergeben (Durch einen Klick auf die Bilder werden diese in größerer Auflösung gezeigt):

scup10  scup11 scup12 scup13 scup14

 

Einrichtung SCUP

Nun kann der “System Center Update Publisher” über das Startmenü gestartet werden – dies sollte aber “Als Administrator” geschehen, da es sonst später zu einem Fehler kommt / kommen kann.

scup7

Dieser Fehler tritt später auf, wenn man die SCUP-Konsole ohne die nötigen Rechte startet:

scup9

Als erstes sind die Optionen zu öffnen:

scup8

Dort muss nun die Verbindung zum WSUS-Server konfiguriert werden (dabei Port beachten – WSUS 4.0 läuft auf 8530 (non-SSL) bzw. 8531 (SSL)):

scup16

Nun fehlt noch ein Zertifikat zum signieren der Updates. Hier kann auch ein selbstsigniertes Zertifikat erzeugt und verwendet werden. Dies geschieht über den “Create”-Button:

scup16b

Dieses Zertifikat muss später noch weiter “behandelt” werden. Als nächster Step wird im SCUP die Verbindung zum SCCM definiert:

scup17

Zertifikat passend einbinden

Das WSUS-/SCUP-Zertifikat muss nun in die “Trusted Publishers” (Vertrauenswürdige Herausgeber) und die “Trusted Root Certificates” (Vertrauenswürdige Stammzertifizierungsstellen) des Computer-Kontos (WSUS/SCUP-Server) importiert werden, vorher muss es natürlich exportiert werden:

scup18 scup18b scup19 scup20

Updates über SCUP an den WSUS veröffentlichen

Nun können die ersten Updates über den SCUP veröffentlicht werden. Dazu muss zunächst ein Katalog hinzugefügt werden:

scup21

Beispielhaft verwende ich hier den “Adobe Reader X” Katalog:

scup22

Danach können die Updates aus diesem Katalog in den SCUP importiert werden:

scup23

scup24

scup25

scup26

scup27

Nun können die neuen Updates zu einer neuen Veröffentlichung hinzugefügt werden:

scup28

scup29

Diese neue Veröffentlichung (Bei mir heißt sie “März 2015”) kann nun veröffentlicht werden. Dazu wird sie unter “Publications” ausgewählt, die jeweiligen Updates markiert und dann auf “Publish” geklickt.

scup30

Dabei sollten die Updates vom SCUP signiert werden:

scup31

scup32 scup33

Updates über SCCM verteilen

Nun kann im SCCM eine erste Synchronisierung durchgeführt werden. Diese ist nötig, damit der SUP (SCCM) “erfährt”, dass es nun auch Adobe als neuen Hersteller und Adobe Reader als Produkt gibt:

scup34 Um den Vorgang zu beobachten bietet der SCCM ein eigenes Werkzeug, alternativ würde auch CMTrace gegen die WSyncMgr.log funktionieren:

scup35 scup36 scup37scup38

Die letzte Meldung zeigt an, dass die Synchronisierung abgeschlossen ist. Nun kann das neue Produkt (in meinem Fall der Adobe Reader) für die Verteilung durch den SUP aktiviert werden:

scup39 scup40

Dabei ist auch der Reiter “Klassifizierungen” zu beachten – wenn das gewünschte Update ein “Sicherheitsupdate” ist, SUP aber nur “Wichtige Updates” synchronisiert, dann wird man nicht zu einem positiven Ergebnis kommen.

Nun ist noch einmal eine Synchronisierung des SUP nötig, damit dieser die bekannten Updates vom WSUS “kennenlernt”.

scup34

Danach stehen die Updates, in meinem Fall für den Adobe Reader, im SCCM wie ein reguläres Windows Update zur Verfügung und können verteilt und bereitgestellt werden:

scup41

Viel Spaß damit!