Regelmäßig werde ich von Kunden gefragt, was sie tun können, wenn die Systempartition einer Windows-VM droht vollzulaufen. Dank Virtualisierung kann man das VMDK- oder VHD-File ja ganz einfach um ein paar zusätzliche Gigabytes erweitern.
In der Datenträgerverwaltung in Windows muss man die Datenträger ggf. noch neu einlesen und der zusätzliche Speicherplatz wird hinter der Partition angezeigt. Nun kann die Partition mit einem Klick auf "Volume erweitern" erweitert werden.
Soweit so gut.
Sporadisch passiert es jedoch, dass das Volume zwar in der Datenträgerverwaltung erweitert ist, der zusätzliche Speicherplatz im Explorer aber nicht angezeigt wird.
Die Lösung:
Explizites Erweitern des Dateisystems mit "diskpart.exe". Der entscheidende Befehl nach dem Auswählen des Volumes lautet: "extend filesystem".
Einen Microsoft KB-Artikel zu diesem Problem findet man hier: http://support.microsoft.com/?scid=kb%3Ben-us%3B832316&x=13&y=9
Eine allgemeine Beschreibung von diskpart ist hier zu finden: http://support.microsoft.com/?scid=kb%3Ben-us%3B300415&x=21&y=6
Posts mit dem Label Windows werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Windows werden angezeigt. Alle Posts anzeigen
Mittwoch, 15. September 2010
Freitag, 23. April 2010
Was lange währt...
...wird endlich gut:
Im DHCP-Server von Windows Server 2008 R2 kann man endlich (!) auf einfach Art und Weise ein Lease in eine Reservierung umwandeln (vorher musste man sie immer manuell anlegen und dabei Name, IP- und MAC-Adresse von Hand eingeben). Einfach mit der rechten Maustaste auf die Reservierung klicken und dann auf "Zur Reservierung hinzufügen":
Danke Microsoft! :-)
Im DHCP-Server von Windows Server 2008 R2 kann man endlich (!) auf einfach Art und Weise ein Lease in eine Reservierung umwandeln (vorher musste man sie immer manuell anlegen und dabei Name, IP- und MAC-Adresse von Hand eingeben). Einfach mit der rechten Maustaste auf die Reservierung klicken und dann auf "Zur Reservierung hinzufügen":
Danke Microsoft! :-)
Dienstag, 20. Oktober 2009
Sysprep 1, 2, 3 - vorbei!
Man lernt ja tatsächlich niemals aus. ;-)
Heute war ich bei einem Kunden, bei dem wir eine virtuelle XenApp 5-Umgebung (unter VMware vSphere 4) auf Basis von Windows Server 2008 x64 betreiben.
Unser Wunsch war, es das Rapid Deployment der Farm so zu gestalten, dass aus einem ge-sysprep-ten Template alle weiteren Farmmitglieder gecloned werden.
Das ist ein an sich bewährtes Verfahren für "kleine" XenApp-Farmen (ich würde sagen bis hinzu ca. 5 bis 10 logischen Servern) und hat über Jahre hinweg auch sehr gut funktioniert.
Nun weiß man ja, wie das ist: man baut so ein Image hat es fertig und syspreped es. Ach "mérde!" eine Kleinigkeit vergessen, also kurz noch einmal anpassen das Image und noch einmal syspreppen. Dann einen Monat (und viele Microsoft Patchdays) später, kommt die Erkenntnis, dass man mal wieder an das Image ranmüsste. Also ein drittes mal syspreppen. Die Welt ist immer noch in Ordnung.
Versucht man es jetzt aber dann - aus welchem Grund auch immer - ein viertes Mal, wird man bitter enttäuscht.
Beim Versuch Sysprep (mit der Generalisierungs-Option) aufzurufen, hagelt es bitterböse Fehlermeldungen, die unter %windir%\System32\Sysprep\Panther\Setuperr.log nachzulesen sind.
Fehler [0x0f0082] SYSPRP LaunchDll: Fehler beim Ausführen von "C:\Windows\System32\slc.dll, SLReArmWindows', ist aufgetreten Fehlercode-1073425657 zurückgegeben
Fehler [0x0f0070] SYSPRP RunExternalDlls: Fehler beim Ausführen Registrierung Sysprep DLLs, die Ausführung von Sysprep anzuhalten. DwRet =-1073425657
Fehler [0x0f00a8] SYSPRP WinMain: Treffer Fehler während der Verarbeitung Sysprep Anbieter verallgemeinern, hr = 0xc004d307
Tja, googled man ein wenig, findet man in der Microsoft Knowledgebase folgende Hinweise:
Ursache: This error may occur if the Windows Software Licensing Rearm program has run more than three times in a single Windows image.
Lösung: To resolve this issue, you must rebuild the image.
Also, man darf sein Image neu bauen.
Der KB-Artikel von Microsoft verwirrt im ersten Moment ein wenig. Dort heißt es: To work around this issue, use the "SkipRearm" setting in an XML answer file (Unattend.xml) to skip the Rearm process when you build the Windows Vista image.
Von einem Workaround kann aber nicht die Rede sein. Denn was hier nicht steht ist, dass man *vor* dem dritten Mal Syspreppen die unattend.xml hätte erstellen müssen, die das sog. "rearm"-ing des Builds verhindert.
Für mich war das echt neu und somit hielt sich die Begeisterung echt in Grenzen.
Ich kann nur von Glück sagen, dass der Kunde ein nicht ganz frisches Backup (Stand Sysprep zum Ersten) "auf Tasch" hatte. Mit dem Stand hatte ich also noch zwei Schuss frei und konnte somit also das Rapid Deployment der Umgebung durchführen.
Es bestätigte sich also was ich schon seit Jahren predige: Cloneing von XenApp-Servern gilt es zu vermeiden. Automatisierte Installationen (á la WDS, WIM, OSD, NetInstall) oder besser noch die Königslösung mit dem Citrix Provisioning Server sind das einzig wahre.
Wieder ein Stückchen schlauer...
Übrigens: NewSID von Sysinternals funktioniert auch nicht unter Windows Server 2008 x64 und unter 2008 R2 schon mal gar nicht.
Momentan ist mir keine andere Technologie bekannt, mit der ich doch noch Microsoft-konform die SID des Clones anpassen könnte.
Ach ja: Schuld ist natürlich die dämliche (Sorry MS...) Produktaktivierung die trotz eines laufenden KMS keine dritte Aktivierung zulässt.
Sonntag, 2. August 2009
Group Policy Drive Maps und UAC (User Account Control)
Wer schon mal Laufwerke per Gruppenrichtlinie verbunden hat, hat sich vielleicht auch schon gewundert, warum das auf Servern mit Windows Server 2008 nicht zu funktionieren scheint. Der Grund ist die standardmäßig aktivierte UAC!
Das Laufwerk wird beim Anmelden quasi nur mit dem vollen Administrator-Token verbunden und ist mit dem eingeschränkten Token dann nicht sichtbar.
Um das Laufwerk sichtbar zu machen, muß man in der Registry-Wert ein DWORD namens "EnableLinkedConnections" unter "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" erstellen und auf den Wert "1" setzen.
Das Laufwerk wird beim Anmelden quasi nur mit dem vollen Administrator-Token verbunden und ist mit dem eingeschränkten Token dann nicht sichtbar.
Um das Laufwerk sichtbar zu machen, muß man in der Registry-Wert ein DWORD namens "EnableLinkedConnections" unter "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" erstellen und auf den Wert "1" setzen.
Freitag, 29. Mai 2009
Telnet Client unter Windows Vista/2008/7 installieren
Jeder der schnell mal einen Server/Port auf dessen Verfügbarkeit prüfen möchte hat sicherlich schonmal Telnet genutzt.
Einfach auf der Kommandozeile "telnet serverip port" eingeben, beispielsweise telnet 192.168.1.1 80, und schon wird die Gegenstelle auf Verfügbarkeit geprüft.
Das Vorgehen ist aber unter Windows Vista, Windows Server 2008 und Windows 7 nicht mehr ganz so einfach, denn gibt man telnet ein erhält man nur folgende Fehlermeldung:
Windows kennt telnet nicht? Das kann doch nicht sein!
Abhilfe schafft folgender kleiner Kommandozeilenbefehl, welcher natürlich mit Administratorrechten eingegeben werden muss:
Einfach auf der Kommandozeile "telnet serverip port" eingeben, beispielsweise telnet 192.168.1.1 80, und schon wird die Gegenstelle auf Verfügbarkeit geprüft.
Das Vorgehen ist aber unter Windows Vista, Windows Server 2008 und Windows 7 nicht mehr ganz so einfach, denn gibt man telnet ein erhält man nur folgende Fehlermeldung:
Windows kennt telnet nicht? Das kann doch nicht sein!
Abhilfe schafft folgender kleiner Kommandozeilenbefehl, welcher natürlich mit Administratorrechten eingegeben werden muss:
pkgmgr /iu:TelnetClientUnd schon kann einige Sekunden später wieder nach Herzenslust "getelneted" werden.
Freitag, 22. Mai 2009
Langsame Anmeldung bei installiertem IE7
Letztens sprach mich ein Kunde an, daß ihm die Anmeldung an den XenApp-Terminalservern sehr lange vorkommt (neu aufgebaute Windows Server 2003 XenApp 5-Farm mit CAG-Anmeldung). Nach Aktivierung des UserEnvDebugLevels (http://support.microsoft.com/?scid=kb%3Ben-us%3B221833&x=11&y=8) und einer genauen Analyse, stellte sich heraus, daß u.a. der Prozess „userinit.exe“ sehr lange braucht.
Ich bin dann auf folgenden KB-Artikel gestoßen: http://support.microsoft.com/?scid=kb%3Ben-us%3B941158&x=9&y=9
Und tatsächlich, in der Log-Datei „%UserProfile%\Local Settings\Application Data\Microsoft\Internet Explorer\Brndlog.txt“ war die im Artikel beschriebene 20-Sekündige Pause zu sehen. Nachdem der Hotfix installiert (gibt’s für x86 nur in Englisch, funktioniert aber trotzdem auf deutschen Systemen) und der entsprechende Registry-Key erstellt wurde, flutschte dann auch die Anmeldung! :-)
Das Problem tritt immer dann auf, wenn der IE7 installiert ist, und auf den Rechner eine GPO wirkt, die die Einstellungen unter „Internet Explorer-Wartung“ aktiviert hat. Also nicht nur auf Terminalservern, sondern auch auf Workstations!
Ich bin dann auf folgenden KB-Artikel gestoßen: http://support.microsoft.com/?scid=kb%3Ben-us%3B941158&x=9&y=9
Und tatsächlich, in der Log-Datei „%UserProfile%\Local Settings\Application Data\Microsoft\Internet Explorer\Brndlog.txt“ war die im Artikel beschriebene 20-Sekündige Pause zu sehen. Nachdem der Hotfix installiert (gibt’s für x86 nur in Englisch, funktioniert aber trotzdem auf deutschen Systemen) und der entsprechende Registry-Key erstellt wurde, flutschte dann auch die Anmeldung! :-)
Das Problem tritt immer dann auf, wenn der IE7 installiert ist, und auf den Rechner eine GPO wirkt, die die Einstellungen unter „Internet Explorer-Wartung“ aktiviert hat. Also nicht nur auf Terminalservern, sondern auch auf Workstations!
Abonnieren
Posts (Atom)