Seit Windows 10 1809 funktioniert der Befehl “Set-PSReadlineOption –TokenKind” zum ändern der einzelnen Textfarben in PowerShell nicht mehr wie ich es in einem früheren Blog Post erklärt hatte. Ab Windows 10 1809 bzw folgender Modulversion wird das festlegen der einzelnen Farben jetzt nicht mehr über ein Tokenkind definiert. Stattdessen wird jetzt mit einer Art Hashtable gearbeitet. Ich habe eine PowerShell Profile Example Datei erstellt welche ich auch über ein GitHub Projekt zur Verfügung stelle. Da es teilweise Umgebungen gibt in denen PowerShell Profile zentral verwaltet und verteilt werden habe ich mein PowerShell Profil mit einer Abfrage versehen sodass die Befehle je nach betreffender Modulversion ausgewählt werden.
Da das Release von Server 2019 in greifbare Nähe gerückt ist will ich mal für euch Beleuchten mit welchen Funktionen und Neuerungen uns Microsoft überraschen will. Der Großteil der Neuerungen richtet an die Verbesserung bestehender Funktionen und verbesserte Hybrid bzw. Cloud Integration. Gleich beginnen will ich mit FoD (Feature on Demand Package für den Server Core). Das FoD Packet beeinhaltet steht als eigenständige ISO zum Download bereit und lässt sich auf dem Windows Server 2019 Core installieren um den Server mit weiteren Funktionen und Binärdateien zu Versorgung sodass eine bessere Anwendungskompatibilität gegeben ist. Durch diese Erweiterungen können jetzt mehr Anwendungen auf der Core Variante installiert werden die bestimmte Bestandteile der “Desktop Experience” erfordern. Durch diese Erweiterung wird zb. InternetExplorer, GeräteManager, DateiExplorer und viele weitere Komponenten installiert. Auch für das FailoverCluster hat sich Microsoft einiges einfallen lassen. So lässt sich jetzt zum Beispiel ein sogenanntes Cluster Set erstellen welches eine lose Gruppierung von Clustern darstellt und somit die Zahl der möglichen Cluster Knoten innerhalb eines SDDC (Software Defined-Data-Center) erhöht. Desweiteren ist es jetzt möglich Failover Cluster zwischen verschiedenen Domänen zu verschieben ohne das man das Cluster auflösen muss wie es bisher erforderlich war. Aus Sicherheitsgründen unterstützt das FailoverCluster jetzt auch keine NTLM Authentifizierung mehr sondern verwendet ausschließlich Kerberos und Zertifikatbasierte Authentifizierung. Die mit Server 2016 eingeführten Windows Server Container die auf der Container Technologie Docker basieren werden vermutlich jetzt auch Linux basierte Container OS Images unterstützen. Desweiteren wird neben dem NanoServer und WindowsServerCore ein weiteres “Basisimage” eingeführt welches zusätzliche Grafische Komponenten beinhaltet wie zum Beispiel Direct X. Auch Kubernetes zum Erstellen, monitoren und skalieren von Containern wird jetzt auf Windows Server 2019 unterstützt. Windows Defender Advanced Threat Protection wurde jetzt vollständig auch in den Windows Server 2019 integriert, welche sich kostenlos über folgenden Link testen lässt: https://www.microsoft.com/en-us/windowsforbusiness/windows-atp. Der Exploit Guard welcher ebenfalls Teil des ATP ist vereint Sicherheitsfeatures wie: Attack Surface Reduction: Ermöglicht es Schadhafte Dateien vom Server fern zu halten wie Office Dateien, Skripte und E-Mail basierte Gefahren . Network protection: Schützt gegen Webbasierte Gefahren in dem Netzwerkverkehr zu nicht vertrauenswürdigen Hosts / IP Adressen durch Windows Defender Smart Screen geprüft und blockiert wird. Controlled folder access: Ist vielleicht schon bekannt aus der aktuellen Windows 10 Version welche es uns ermöglicht nicht vertrauenswürdige Prozesse den Zugriff auf Sensitive Dateien und Ordner zu blockieren. In den Storage Funktionen wie zb Storage Spaces Direct oder Storage Replica wurde noch weiter an der Performance Schraube gedreht. So steht jetzt zum Beispiel für die Storage Spaces Direct eine Performance History zur Verfügung mit der es Möglich ist die Performance des Cluster mitzuloggen und anschließend mit dem neu eingeführten Admin Center zu visualisieren. Storage Replica wurde mit Server 2016 als Datacenter Funktion eingeführt und ist eine Technologie um eine synchrone oder asynchrone Replikation des Storage Systems auf Partitionsebene für zum Beispiel Desaster Recovery zu ermöglichen. Desweiteren bekommen wir durch die Storage Replica die Möglichkeit ein sogenanntes streched Failover Cluster zu erstellen welches sich über weiter entfernte Standorte erstrecken kann. Mit Einführung von Server 2019 wird diese Funktion ebenfalls auf der Standard Edition zur Verfügung stehen allerdings mit ein paar Einschränkungen gegenüber der Datacenter Version. So wird es nur möglich sein ein einzelnes Volume anstatt unbegrenzt zu replizieren sowie auch nur pro Volume einzelne Partnerschaften möglich sein. Auch die Volumegröße wurde auf 2 TB begrenzt in der Standard Edition. Eine Neue Funktion die mich persönlich erfreut ist der Storage Migration Service , der es uns einfach ermöglicht ältere Dateiserver ab Server 2003 einfach auf Server 2019 oder Richtung Azure zu migrieren. Es wird lediglich ein Server 2019 benötigt der als Orchestrator arbeitet und die bestehenden Daten, Sicherheits- und Netzwerkeinstellungen inventarisiert und mithilfe eines Workflows über das Windows Admin Center auf das neue Ziel überträgt, welches aktuell entweder ein Server 2019 oder ein Ziel in der Cloud sein kann. Bei Bedarf wird der alte Server komplett zurückgebaut und die Identität auf den neuen Server umgezogen in einer Weise die diesen Vorgang für User unsichtbar macht. Das Windows Admin Center dem ein oder anderen auch vielleicht bekannt unter dem Projekt Namen “Honolulu” ist eine web basierte Oberfläche welche es ermöglich die Server innerhalb des Netzwerks und von Azure über den Browser zu administrieren und zu monitoren. Das Windows Admin Center kann Server zurück bis Windows Server 2008R2 verwalten solange auf diesen das aktuelle Windows Management Framework mit der PowerShell Version 5.1 installiert ist. Über dieses Admin Center kann auch die neue Funktion System Insights verwendet werden welche die Ressourcen Daten eines Servers mit loggt und eine Prognose erstellt sodass früh genug neue Hardware angeschafft oder bestehende Hardware geupgradet werden kann. All diese Neuerungen haben wir auch bereits in unserem neuen Kurs “Windows Server 2019 - Neuerungen” eingebaut welcher ab sofort auch die neuen Themen behandelt. Alle Neuerungen können auch nochmal hier: https://docs.microsoft.com/en-us/windows-insider/at-work/whats-new-wip-at-work nachgelesen werden.
Da ich in meinen Kursen immer öfters an die Frage stoße wie man Vorschaubilder im Windows Explorer anzeigen kann. Heute mal ein kurzer Blogartikel dazu. Im Normalfall sieht man Bilder im Datei Explorer nur als Symbol Da es aber gerade für Web oder Fileserver interessant sein kann auch am Server die Bilder sehen zu können ohne diese extra öffnen zu müssen hier der kurze Weg. Und der Einfachheit halber einfach kurz mit dem “Problem Steps Recorder” (psr.exe) aufgenommen. Step 1: Klick mit der linken Maustaste durch Benutzer auf "Registerkarte 'Datei' (Schaltfläche)" in "Bilder" Step 2: Klick mit der linken Maustaste durch Benutzer auf "Ordner- und Suchoptionen ändern (Menüelement)" Step 3: Klick mit der linken Maustaste durch Benutzer auf "Ansicht (Registerkartenelement)" in "Ordneroptionen" Step 4: Klick mit der linken Maustaste durch Benutzer auf "Immer Symbole statt Miniaturansichten anzeigen (Strukturelement)" in "Ordneroptionen" Step 5: Klick mit der linken Maustaste durch Benutzer auf "OK (Schaltfläche)" in "Ordneroptionen" Step 6: Klick mit der linken Maustaste durch Benutzer auf "Elementansicht (Liste)" in "Bilder"
Microsoft veröffentlicht eine neue Windows Server Insider Preview und von mir, bekommt ihr die wicht
[Mehr]
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: 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: 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: 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: Der neue Windows Server bringt noch eine neue Rolle mit, die in der bisherigen Preview nicht enthalten war: 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: Mal sehen was ich noch so finde – ich bleibe auf jeden Fall dran!
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: “Auswählen der Gesamtstruktur-Stammdomäne” (https://technet.microsoft.com/de-de/library/cc726016(v=ws.10).aspx) “Namenskonventionen in Active Directory für Computer, Domänen, Standorte und Organisationseinheiten” (https://support.microsoft.com/de-de/kb/909264) “Why you shouldn't use .local in your Active Directory domain name.” (http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html) “ACTIVE DIRECTORY DOMAIN NAMING BEST PRACTICES” (http://blog.varonis.com/active-directory-domain-naming-best-practices/)
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:
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:
Auf einem Windows Server 2012 / 2012 R2 ist dieses Patch nicht nötig – hier läuft WSUS 4.0!
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):
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.
Dieser Fehler tritt später auf, wenn man die SCUP-Konsole ohne die nötigen Rechte startet:
Als erstes sind die Optionen zu öffnen:
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)):
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:
Dieses Zertifikat muss später noch weiter “behandelt” werden. Als nächster Step wird im SCUP die Verbindung zum SCCM definiert:
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:
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:
Beispielhaft verwende ich hier den “Adobe Reader X” Katalog:
Danach können die Updates aus diesem Katalog in den SCUP importiert werden:
Nun können die neuen Updates zu einer neuen Veröffentlichung hinzugefügt werden:
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.
Dabei sollten die Updates vom SCUP signiert werden:
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:
Um den Vorgang zu beobachten bietet der SCCM ein eigenes Werkzeug, alternativ würde auch CMTrace gegen die WSyncMgr.log funktionieren:
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:
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”.
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:
Viel Spaß damit!
Sie benötigen weitere Informationen zum SCCM und den Möglichkeiten, Updates zu verteilen? Dann schauen Sie sich unseren Kurs zum System Center Configuration Manager 2012 R2 an!
.postitem li{
line-height: 20px !important;
} Seit Windows Server 2008 und Windows Vista gibt es die Möglichkeit Drucker per Gruppenrichtlinien komfortabel bereitzustellen. Voraussetzungen hierfür: AD-Funktionsebene mindestens Windows Server 2008 Drucker müssen über einen Printserver mit mindestens Windows Server 2008 freigegeben werden Client-Betriebssystem mindestens Windows Vista Auf einem Domaincontroller in der Gruppenrichtlinienverwaltung erstellt man sich zunächst ein neues Gruppenrichtlinienobjekt. Auf dem Printserver muss die Rolle “Druck- und Dokumentdienste” installiert sein. Hier genügt der Rollendienst “Druckerserver”. Damit steht das Snap-In “Druckverwaltung” zur Verfügung. In dem Snap-In “Druckverwaltung” macht man unter “Drucker” auf den Drucker, den man bereitstellen möchte, einen Rechtsklick. Im Kontextmenü ist der Eintrag “Mit Gruppenrichtlinie bereitstellen” zu finden. Über den Button “Durchsuchen” (1) wählt man das Gruppenrichtlinienobjekt aus, über das der Drucker bereitstellt werden soll (Hinweis: Wenn das GPO noch mit keiner OU verknüpft ist, muss auf die Registrierkarte “Alle” gewechselt werden, um das GPO zu sehen). Nach dem Auswählen des GPO muss noch definiert werden, ob der Drucker über die Computer- oder die Benutzerkonfiguration bereitgestellt werden soll (2). Abschließend noch auf den Button “Hinzufügen” klicken, damit das GPO in die Liste aufgenommen wird. Es ist also ohne Probleme möglich einen Drucker über mehrere GPOs bereitzustellen! Das war’s! Sobald die Gruppenrichtlinien auf die entsprechenden Computer bzw. Benutzer angewandt werden, wird automatisch der Drucker installiert und steht damit zur Verfügung. Um einen Drucker bei Computer bzw. Benutzer wieder zu entfernen, muss über die Druckverwaltung das Gruppenrichtlinienobjekt einfach wieder über “Mit Gruppenrichtlinie bereitstellen” aus der Liste entfernt werden.
Die aktuelle Build 9841 des kommenden Windows Server (aktuell als “vNext” bezeichnet, vermutlich später “Windows Server 2016”, da erst Mitte 2016 erscheinen wird) bringt neben einigen anderen neuen Funktionen auch ein Feature “Soft Restart” mit: Unabhängig davon, ob es installiert ist oder nicht, stehen sowohl in der CMD via shutdown.exe als auch in der PowerShell passende Optionen zur Verfügung: Von den Funktionen erwarte ich mir, dass sie den Server neustarten, ohne die gesamte Hardware neu starten zu müssen (verbunden mit den ganzen POST-Checks und co., RAID-Controller und alles was beim Booten eben so auf einem Server Zeit kostet). Dadurch sollte der Reboot auch deutlich schneller sein, was auch Downtimes nach Updates deutlich verkürzen würde. Leider haben beide Schalter (“shutdown.exe /soft” und “Restart-Computer –Soft”) in der aktuellsten freien Build (9841) noch keine Auswirkung und zeigen auch keinerlei Verkürzung der Boot-Zeit. Auch nach der Installation des Features und dem dadurch notwendigen Reboot ändert sich nichts. Schade. Also abwarten…
Wenn man einen DHCP-Server betreibt, dann sollte dies bevorzugter Weise in einer Domäne geschehen – also mit dem DHCP-Server als Mitglied des Active Directory. Dort benötigt dieser eine Autorisierung, welche dafür sorgt, dass dieser Server dann auf eingehende Anfragen (DHCP Request) reagiert. Solange er nicht autorisiert ist, vergibt er auch keine Adressen. Soweit so gut. Wenn man einen DHCP-Server NICHT in Active Directory integriert, kann man ihn auch nicht autorisieren, er verrichtet dennoch seine Dienste – bis er auf einen autorisierten Server trifft! Dann nämlich wird der nicht autorisierte Server (der nicht Mitglied der Domäne ist) seinen Dienst einstellen und selbst wenn man ihn wieder manuell aktiviert sich sofort wieder abschalten. Damit ist es also nicht so ohne Weiteres möglich, zwei DHCP-Server im selben Netz zu betreiben. Nun kann es aber sein, dass genau das gewünscht ist – weil die Server z.B. Adressen für unterschiedliche MAC-Adressen verteilen. Hier muss man also eingreifen und den nicht-autorisierten DHCP Server daran hindern, sich abzuschalten. Das “Zauberwort” hier heißt “Rogue Detection” – und genau die muss deaktiviert werden. Dies geht nicht über eine GUI, sondern muss über eine Registrierungswert geändert werden. Dieser heisst KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters \DisableRogueDetection Mittels des folgenden Aufrufs lässt sich der Eintrag recht schnell anlegen: reg add HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\DHCPServer\Parameters /v DisableRogueDetection /t REG_DWORD /d 1 Dieser Schlüssel ist sehr oberflächlich in folgendem KB-Artikel bei Microsoft beschrieben: https://support.microsoft.com/kb/949530