Endlich ist es soweit. Die Public Beta oder eben die Windows 8 Consumer Preview ist da. Ihr könnt sie hier runter laden:
Client:
http://windows.microsoft.com/en-US/windows-8/iso
Server:
http://msdn.microsoft.com/en-us/evalcenter/hh708764.aspx
Viel Spass beim testen
Was für die meisten Arbeitgeber ein Graus ist und für die meisten Arbeitnehmer nicht so richtig nachvollziehbar- das ist für uns bei der Microsoft Schweiz schon länger Realität. Arbeiten von unterwegs, arbeiten von zu Hause aus. Neue flexible Arbeitsmodelle, nicht mehr gebunden an klassische Arbeitszeiten. Das Magazin 10 vor 10 des Schweizer Fernsehens hat darüber einen interessanten Beitrag gemacht:
Folgendes Problem: Der Kunde kommt zu dir und erzählt dir das er einen Drucker in Büro xyz ersetzen musste. Soweit so gut. Nur ist der Ersatzdrucker nicht ansprechbar. Respektive, manchmal ist er ansprechbar, gibt aber bei einem Ping übers LAN nur einen Netbios Namen zurück und keinen FQDN...
Aufgefallen ist das Problem dadurch dass im Büro xyz ein Drucker mit irgendeinem Namen den Namen des ursprünglichen Druckers übernehmen musste. Man halt also einen Ersatzdrucker ins Büro gestellt und dem den Namen des defekten gegeben- so dass der Benutzer auf den gleichen Drucker arbeiten kann. Theoretisch... Man muss dazu noch sagen dass alle Drucker über DHCP laufen, daher nur der Host / Netbios Name auf dem Drucker eingetragen wird und der Rest dann automatisch laufen sollte. So muss man kein IP Management für die Drucker machen- was bei dem Kunden immerhin 1'000 Stück an der Zahl sind.
Nur leider hat dies nicht so geklappt und es hat auch bei anderen Druckern nicht geklappt. Langsam erkannt der Kunde einen roten Faden durch seine Druckerlandschaft, da Drucker nicht mehr ansprechbar waren nach einem Stromunterbruch- einige sogar nach einem kurzen Netzunterbruch. Wo vorher ein Drucker geantworet hatte- war nun keiner mehr.
Nach kurzer Zeit schrien dann alle DNS Probleme, DNS Probleme... was auch wirklich danach aussah.
Gut, ich nahm mir dann mal so einen Drucker vor und druckte die Konfigseite aus. IP hatte er, Namen auch, die IP war pingbar, der Namen manchmal, jedoch nur der Netbios Name... hmmm
Ich öffnete die Webkonsole des Druckers und suchte nach den DNS Einstellungen... aber da waren keine. Es stellte sich raus das der Drucker eine Firmware aus 2006 hatte, es aber keine neue gab. Was er aber hatte- er hatte die WINS Server eingetragen die noch im Netz sind.
Ihr erinnert Euch? WINS?
http://en.wikipedia.org/wiki/Windows_Internet_Name_Service
Die Drucker leider schon out of support, letzte downloadbare Firmware vom 2006. Hurra dachte ich.
Der Kunde war sich bewusst das die Drucker alt sind- dies können aber nicht abgelöst werden da noch Applkationen über SNA auf diese Dinger drucken und so lange diese Applikation noch im Einsatz ist (1-3 Jahre), so lange müssen auch die Drucker bleiben. Ich hätte dann gerne den Druckerhersteller ins Boot geholt- dieser wollte aber nicht mehr so recht, von wegen kein Support mehr und überhaupt. Da wir bei Microsoft aber dem Kunden helfen wollen, versuchte ich der Sache von der Infrastruktur Seite her auf den Grund zu gehen.
Wir hatten also Drucker die sich in WINS registrieren zu schienen- daher kam auch der Netbios Name zurück beim Ping, aber auch nicht immer. Eine DNS Registration fand wohl nicht statt, sonst hätte der Ping einen FQDN zurück geben müssen.
Da die Drucker kein DNS konnten und uns WINS nicht reichte für die Namensauflösung, musste ein anderer Mechanismus ran. Wenn wir mit solchen Legacy (Altlast) Clients wie diesen Druckern umgehen müssen, beitet uns der DHCP und DNS Server in Windows einiges an Hilfe. In dem Fall gehe ich von Windows Server 2008 R2 aus.Wir können nämlich dem DHCP sagen, dass er die gesamte Verwaltung der DNS Einträge übernehmen soll- zumindest für die Clients denen er eine IP vergibt. Hierzu entmündigen wir also die Clients und lassen sie nicht mehr selber ihre Registration und Updates im DNS machen, sondern geben den Job vollumfänglich dem DHCP. Man könnte auch die dies können selber machen lassen und die anderen den DHCP- was ich aber nicht empfehle. Im Sinne von einem Mechanismus würde ich hier dem DHCP die ganze Authorität übergeben. Um das zu bewerkstelligen, brauchen wir einen DHCP, einen DNS und einen Service Account in der AD- der jedoch nur Domain Users Rechte hat. Den Benutzer hinterlegen wir in der DHCP Konfiguration, so dass der DHCP im Namen aller beim DNS die Registrationen machen kann.
http://technet.microsoft.com/en-us/library/dd145315(v=WS.10).aspx
Wenn man den Benutzer hinterlegt hat und den DHCP Dienst neu gestartet, kann man dem DHCP die ganze Registration übergeben:
Diese Optionen waren aber alle schon eingestellt- wieseo bekamen dann die Drucker keinen FQDN Namen? Ein Blick in die DNS Zone offenbarte das auch keine Einträge da waren- zumindest meistens. Ein Blick auf die DHCP Scopes zeigte dann dass die Lease Time viel zu tief eingestellt war. Mit einer Lease Time von 15 Minuten war die Umgebung nur noch den DHCP und DNS am zuschiessen, es waren immerhin fast 4'000 Geräte die was vom DHCP oder dem DNS wollten alle 15 Minuten! Also änderte ich alle Scopes auf eine Lease Time von 8 Tagen was Default ist. Somit passte nun auch das Scavening der Zone mit 7 Tagen wunderbar. Vorher konnte dies gar nicht richtig funktionieren, da sich alles in die Quere kam.
Ein guter Artikel zu dem Thema:
Nun waren wir auf dem richtigen Weg, doch es schien immer noch zu hacken. Ich bemerkte dann das der Kunde sämtliche Anfragen im Netz auf die beiden gleichen DNS Server schickte- natürlich auch noch virtuelle DNS auf älterer Hardware. Lange Rede, kurzer Sinn, die Kisten waren zugeflutet mit DNS Anfragen und konnten die hohe Anzahl nicht abarbeiten. Dies reusltierte dann in langen Queues, die Lease Time lief alle 15 Minuten ab und somit war an der Registrations- Front nur noch Chaos. Die Kisten konnten die Flut nicht übernehmen. Da der Kunde glücklicherweise einen fetten Hardware DC kürzlich installiert hatte- der natürlich nichts tat den ganzen Tag, änderte ich auf dem DHCP den Primären DNS auf die neue Hardware. Somit wurden die Anfragen von DHCP nun an diesen geleitet und nicht mehr an den virtuellen.
Und siehe da- eine halbe Stunde später hatte sich alles gelegt, wir konnten dem Drucker 5 mal den Namen ändern und der antwortete innerhalb 30 - 180 Sekunden mit dem neuen richtigen FQDN.
Daher sollte man aus dem Artikel auch mitnehmen das virtualisierung zwar was tolles ist- verliert aber nicht das Sizing aus den Augen, den wenn ihr physische Server hinstellt, überlegt ihr euch vorher auch ob die Hardware genügend Power hat.
Heute durfte ich bei meinen Kollegen über das neue Windows Logo lesen. Taraaaa:
Das blaue, schlichte an den Metro Stil angelehnte Logo ist das neue Windows Logo das mit Windows 8 Einzug halten wird. Darunter seht Ihr eine Auflistung aller bisherigen Logos- da werden Erinnerungen wach!
Aber lest den ganzen Artikel bei meinen Kollegen vom Windowsblog:
Ich habe kürzlich bei einem Kunden die gesamte Domänen- Infrastruktur von Windows 2003 Server auf Windows Server 2008 R2 im nativen R2 Modus gehoben.
So weit so gut, es lief alles wie erwartet. Der Kunde, der mehrere Netzwerkverbindungen zu Lieferanten hat, meldete jedoch Probleme mit Webapplikationen seiner Lieferanten. Konkret "froren" die Applikationen immer wieder ein, unabhängig vom Browser. Teilweise waren sie gar nicht aufrufbar, oder nur nachdem man mehrmals die Refresh Funktion des Browsers betätigt hatte. Relativ schnell wurde klar dass dies etwas mit der Umstellung auf Windows Server 2008 R2 zu tun haben musste.
Ich ging daher daran dem Weg des Browsers nachzugehen. Da im Internet alles über Namen passiert, nahm ich die DNS Konfiguration näher unter die Lupe. Klar stellte der Kunde fest, das es vor der Umstellung immer lief :-)
Die besagten Webapplikationen wurden über DNS Namen aufgerufen. Da die Namensverwaltung der Applikationen in der Herrschaft der Lieferanten lag, hatte ich lediglich 2 Anhaltspunkte:
Natürlich versuchte ich zuerst den Fehler beim Lieferanten zu finden. Dies war jedoch nicht wirklich leicht, da der Lieferant die Dienste in Asien hostet und die Kommunikation zum Lieferanten sich daher relativ schwer gestaltete. Ich denke ihr kennt das Problem- ihr steht einem Internationalen Unternehmen mit einer unglaublich grossen IT Landschaft gegenüber und die Wege die richtige Person in deren Organisation zu finden, gestalten sich mehr als schwer.
Der Kunde schloss das Problem auf Seite Lieferant aus- schliesslich lief es ja vor der Umstellung.
Ich ging also daran die interne DNS Struktur auseinander zu nehmen.
Der Client registrierte sich auf einem DNS in seiner Zone, eine Active Directory integrierte Zone einer Child Domain. Falls die Anfragen nicht beantworten werden konnten, wurden diese an die Root Domain übergeben und schliesslich dann weiter ins Internet. Da die Hersteller Applikationen jedoch nicht übers Internet aufgelöst wurden, bestanden auf dem DNS Conditional Forwarder auf 2 DNS Server der Lieferanten. Diese 2 DNS Server sind über eine dedizierte Netzanbindung zwischen Kunde und Lieferant ansprechbar.
Ich pickte mir einige dieser DNS Namen raus und versuchte diese zu pingen. Meist war ich erfolgreich, nur manchmal war der Namen plötzlich nicht mehr auflösbar um dann 30 Sekunden später wieder auflösbar zu sein:
Es war nicht so das ich einen Timeout erhalten habe, sondern der Name war komplett nicht mehr auflösbar.
Das hat die Lage natürlich nicht erleichtert, da es generell zu funktionieren schien- aber halt nicht immer. Auch schien es Schwankungen in der Stärke des Problems zu geben, nur auch diese nicht rekonstruierbar oder irgendwie auf ein Muster anwendbar. Da der Kunde mit immer grösseren Problemen konfrontiert wurde und daher natürlich auch die Benutzer ihren Unmut an der Hotline äusserten- entschloss ich mich kurzfristig in der Child Domain eine neue Zone zu errichten und die Hosts des Herstellers statisch einzutragen. Die Conditional Forwarder entfernte ich. Nun schien auch kein Problem mehr da zu sein, die Applikationen liefen einwandfrei und die Namensauflösung klappte wunderbar. Doch es wäre nicht IT wenn sich dies nicht schnell wieder geändert hätte. Einige Tage danach hatte der Hersteller einigen der Hosts neue IP Adressen vergeben- mit den statischen Einträgen in unserer DNS Zone passte dies natürlich nicht mehr überein und die Applikationen waren somit gar nicht mehr erreichbar.
Es musste also eine andere Lösung her und ich ging nochmals daran raus zu finden was das Probem mit den Conditional Forwarder sein könnte. Ich nahm mir also Bing zur Hand und durchsuchte das Internet nach Artikeln zu DNS Conditional Forwarder Problemen nach der Migration von 2003 zu 2008. Und ich wurde fündig :-)
In Windows 2003 DNS wurde eine Funktion hinzugefügt die sich EDNS0 nennt. Dabei geht es darum das der DNS UDP Anfragen senden kann die grösser als der Default Wert von 512 Byte ist: Mit der in RFC 2671 definierten Erweiterung des DNS-Protokolls "EDNS0" (Extension Mechanisms for DNS) können DNS-Anforderer die UDP-Paketgröße ankündigen und Pakete mit mehr als 512 Bytes übertragen.
http://technet.microsoft.com/en-us/library/cc785769(v=WS.10).aspx
Nun ist es aber so, dass nicht alle Systeme, resp. auch Firewalls nicht damit umgehen können. Ich fand dazu den Artikel:
http://support.microsoft.com/kb/832223
Dieser beschreibt genau mein Problem und legt auch nahe das die Firewall das Problem sein könnte. Die EDNS0 lässt sich auf dem DNS Server via Command Line abschalten:
dnscmd /config /enableednsprobes 0
Da ich aber nicht einfach ausschalten wollte, schaute ich mir mit dem Kunden die Firewall Logs an und stiess tatsächlich auf viele Einträge die sagten dass die UDP Pakete von dem internen DNS gedropt wurden, da sie nicht die Standard Grösse hatten und sie die Firewall so als potentiell gefährlich einstufte. Wir schauten uns daher die Firewall Regeln in Richtung Lieferant an und fanden tatsächlich eine Option wie sie in dem KB Artikel beschrieben ist, nämlich das Zulassen von UDP DNS Paketen grösser als 512 Byte. Kaum war der Hacken gesetzt, liefen auch die Webapplikationen anstandslos :D
Nun stellte sich natürlich die abschliessende Frage, wieso der Fehler jetzt aufgetreten ist. Schliesslich wurde die Funktionalität in Windows 2003 Server eingeführt und hätte somit schon vorher aktiv sein müssen. Da wir aber keine alten 2003 DC's mehr hatten- mussten wir davon ausgehen dass die Option auf den alten DNS abgeschaltet wurde, nur hatten wir dies wahrscheinlich bei der Migration übersehen. Eine andere Möglichkeit wäre natürlich noch das die Firewall mal einen Update bekam zum Zeitpunkt der Migration- dies konnte mir der Kunde jedoch nicht schlüssig beantworten.
Nach der Anpassung der Firewall Rule sind nie mehr Fehler diesbezüglich aufgetreten.