Gulp

Mir scheint die Partition ist nicht als Aktiv gesetzt ..... Wurde denn neu partitioniert? Oder sollte, wenn nicht neu partitioniert wurde, nicht die Wartungspartition korrekterweise den Bootloader enthalten? Grüsse Gulp

Hmm ich sehe hier absolut keine Bevormundung .... Ehrlich gesagt ist es mir sogar piepsegal wie das Verzeichnis in Wirklichkeit heisst, solange ich per Explorer oder CMD dorthin komme. Ich hab das auch gerade mal ausprobiert .... per cd Programme lande ich eben auf c:\Programme, per cd "Program Files" auf c:\Program Files (was ja das Gleiche ist). (das überstimmt gleich meine These, die CMD werte die desktop.ini nicht aus, scheint ja wohl doch. Lediglich ein Directory Listing blendet offensichtlich die JunctionPoints aus. Ist aber wohl auch besser so, sonst kämen bestimmt ein paar User auf den glorreichen Gedanken einen der "doppelten" Ordner zu löschen ..... ;) ) Ich hasse es eher wenn Entwickler nicht mächtig sind mit Variablen zu arbeiten und man unter XP einmal den Ordner Programme und einmal den Ordner Program Files unter C: findet weil man nicht mächtig oder zu faul ist Variablen wie %program_files% im Installationsskript anzuwenden. Das empfinde ich, für mich, eher als Bevormundung. Unter Vista ist's damit endlich Essig, da landet alles in c:\Program Files oder c:\Programme oder wie es auch immer in der jeweiligen Landessprache heisst. Ich sehe da eigentlich nur Vorteile drin. Grüsse Gulp

Na ganz einfach, der Explorer zeigt folgendes in der Adressleiste an: "Programme" Du klickst halt irgendwo in den restlichen Bereich der Adressleiste (nicht auf den Namen "Programme", am Besten dahinter, so dass man "Programme" nicht markiert) und schon steht in der Adressleiste "C:\Program Files". Die Umbennung oder Lokalisierung der JunctionPoints funktioniert über die Datei "desktop.ini" deshalb kann die Kommandozeile dies nicht anzeigen, die wertet im Gegensatz zum Explorer die "desktop.ini" nicht aus. Grüsse Gulp

Man kann den Explorer schon dazu animieren den Originalpfad anzuzeigen, allerdings meines Wissens immer nur durch einen Klick in einen freien Bereich der Adressleiste (also etwa hinter dem angezeigten Ordner/Namen). Theoretisch lassen sich alle JunctionPoints über die im jeweiligen Ordner vorhandene "desktop.ini" sogar mit eigenen Namen versehen, bei den Programmordnern oder dem Profilverzeichnis sollte man jedoch tunlichst die Finger von derlei Spielchen lassen, sonst gibt es Probleme mit Programminstallationen oder dem System überhaupt, da viele Aufrufe nur über die JunctionPoints realisiert sind. Grüsse Gulp

Aha ..... Microsoft gibt Version 2 dieses Updates (KB941649) heraus da: Known issue Note This package has been updated to version 2. An issue was identified in which certain computers that have specific combinations of older AHCI USB chipsets and CD or DVD drives that use the SerialATA interconnection bus may not start after the installation of the original version of this package. Version 2 of this package has removed the fix that caused this problem. ..... aus KB941649 Da schätze ich doch mal frech, dass ich nicht der Einzige mit dem Problem war ..... (OK ich gebe zu den ein paar Mal getestet zu haben und auch jedesmal brav einen entsprechenden Problembericht an Microsoft übermittelt habe, so wie Vista das nach jeder Reparatur vorgeschlagen hatte. ;) ) Jetzt geht's ans testen der Version 2 ..... mal sehen, ob der funzt. [update] Bingo, mit Version 2 funktioniert der Hotfix nun auch bei mir ohne Probleme ..... :D [/update] Grüsse Gulp

Bei der Menge an exakten Informationen zur Fehlermeldung hätte ich viele Ideen, leider kann man hier keine Bücher posten .... Ist es wirklich zuviel verlangt wenigstens die Fehlermeldung abzutippen, damit man wenigstens einen Anhaltspunkt hat? Grüsse Gulp

Yepp, exakt ich hab's ein bisschen gekürzt und am Anfang einfacher formuliert, der Teil mit dem 64-bit DMA lässt, so sich finde ich, kaum besser als im c't Artikel erklären. Hier dürfte aber wieder mal die Grenze zwischen Serverhardware mit +4GB Unterstützung und Consumerhardware zu Tage kommen, die theoretisch zwar auch +4GB könnte, aber "nur" mit fetzigen Marketing Sprüchen punktet und leider nur mit dem üblichen "Besteck" unfallfrei umgehen will. [EDIT] Grundsätzlich sollte der Intel P965 schon Memory Remapping beherrschen, das ASUS P5B Deluxe mit Intel P965 hat diese BIOS Option nämlich an Bord. Ob es der jeweilige Hersteller jedoch ins BIOS packt, bleibt aber wie immer dem Hersteller überlassen. Auch laut Intel® 965 Express Chipset Family - Datasheet sollte Memory Remapping für den P965 kein Problem sein.[/EDIT] Grüsse Gulp

Hmm, Memory Remapping spielt eigentlich meistens bei 32-bit Betriebssystemen eine Rolle, da ja hier der PCI Adressraum unterhalb der 4GB eingeblendet werden muss (mehr kann durch 32-bit ja nicht angesprochen werden), durch das Memory Remapping werden die fehlenden Bereiche dann oberhalb von 4GB "angeklebt", sofern das Betriebssystem den Bereich oberhalb von 4GB ansprechen kann (zB durch PAE = Physical Adress Extension). Das können die Serverbetriebssysteme (die 2003 Standard Edtion bis max 4GB in Summe - also unterer Adressbereich + angeklebter Adressbereich über 4GB bis maximal insgesamt 4GB, die 2003Enterprise Edition bis max 32 GB), XP kann zB nur eingeschränkt auf insgesamt 4.294.967.296 Byte (2 hoch 32) oder 4096 MB trotz PAE adressieren, erreicht also die durch das Memory Remapping "angeklebten" Adressbereiche eben nicht. Das ist auch der Grund, dass bei XP 32-bit nie insgesamt 4GB angezeigt werden, ausser das Mainboard BIOS übernimmt die Adressierung übersetzt dies an Windows. Auch bei 64-bit Hardware gibt es dieses Speicherloch, allerdings werden 4GB meistens voll erkannt. Trotz 64-bit Hardware sind einige I/O-Komponenten auf 32-bit Adressen angewiesen, daher kann auch hier Memory Remapping notwendig sein, hier liegt der reservierte Bereich eben einfach oberhalb der tatsächlich physikalisch eingebauten RAM Grösse. All das erklärt erstmal nur das Memory Remapping, das hier aber gar nicht das Problem darstellen wird, sondern: Manche PCI Karten und Chipsätze können nämlich keine 64-Bit-Adressen für Speicherzugriffe generieren (64-Bit-DMA). Das gilt auch dann, wenn sie mit einem passenden Treiber für ein 64-Bit-Betriebssystem laufen. Die meisten PCI-X Karten sollten 64-Bit-DMA schon jetzt können, also etwa GBit-LAN-, U320-SCSI- oder FibreChannel-Hostadapter. Auch viele SATA-Adapter sollen das Verfahren beherrschen. Prinzipiell kann sogar der 32-Bit-PCI-Bus 64-Bit-Adressen per Dual Address Cycles (DAC) übertragen. Doch welche 32-Bit-PCI-Chips DAC-tauglich sind, lässt sich kaum herausfinden - sofern sich überhaupt Datenblätter finden, sind darin 64-Bit-DMA und DAC meistens kein Thema. Ein Register, aus dem sich die 64-Bit-Fähigkeiten per Software auslesen lassen, sehen leider erst neuere Standards wie PCI Express, Serial ATA und HD Audio vor. Intels Dokumentation verrät, dass die ICH6-Southbridges DAC von PCI-Karten durchleiten und dass die integrierten Controller für USB 2.0 (EHCI), SATA sowie HD Audio mit 64-Bit-Adressen hantieren können. Auch der PCI-Express-Anschluss hat damit kein Problem - anders als beispielsweise der AC-97-Controller. Bei I/O-Geräten mit geringer Transferleistung sollten 32-Bit-Zugriffe auf den Speicher kein Problem sein, denn ein x64-Windows greift dann helfend unter die Arme. Ein spezieller Mechanismus, genannt Address Windowing Extensions (AWE), bildet die 32-Bit-Adressen auf den 64-Bit-Adressraum ab. Ein solches Double-Buffering ist allerdings eine Notlösung, die viel Zeit und Prozessorleistung kostet und alle Geschwindigkeitsvorteile der DMA-Idee zunichte macht. Je mehr RAM das System ansteuert, umso mehr Probleme drohen, wenn die I/O-Bauteile 64-Bit-DMA nicht beherrschen und Adressbereiche oberhalb 4 GByte angesprochen werden, was schon bei Remapping der Fall ist. Der Athlon 64 enthält deshalb einen speziellen Memory Controller (IOMMU), der Hardware-Beschleunigung für 64-Bit- und 32-Bit-DMA bietet. Ich fürchte da hilft auch kein BIOS Update. Grüsse Gulp

In den ISO's sind eben nur die Updates des Patchdays, dafür für alle Systeme. Man braucht also von jedem Patchday ein ISO .......... Grüsse Gulp

Mit dem Vorgänger Winternals ERD Commander, ja ..... und ja das funktioniert. Grüsse Gulp

Ich kann Dich zwar verstehen, muss aber trotzdem einwerfen, dass Dir niemand (auch nicht WinFuture) die Authentizität der in den Updatepacks enthaltenen Hotfixes/Patches garantiert. Im feinen Unterschied eben zum c't Tool, dass die Updates ausschliesslich von Microsoft direkt herunterlädt. Hier bestünde zwar theoretisch auch die Möglichkeit einer nachträglichen Veränderung der Updates, aber da Du den Download selbst anstossen musst, ist dies zu vernachlässigen. Sicher gibt es Konstellationen in denen Updatepacks Sinn machen, auch Microsoft hat dies erkannt und bietet mittlerweile ISO's mit den jeweiligen Patchday Updates an. Die ISO's finde ich zwar auch unpraktisch, da man für jeden Patchday ein seperates ISO runterladen muss. Letztlich muss man aber feststellen, dass lediglich die c't Offline Update Methodik, die ISO's von Microsoft, ein WSUS/SUS oder das Update über die Windows/Microsoft Update Seite die Sicherheit geben unveränderte Updates direkt von Microsoft zu beziehen und das ist für mich das Killerargument, dass immer gegen die restlichen Updatepacks spricht. Grüsse Gulp

Da mach Dir mal keinen Kopf, ich hab ein hartes Fell und einen breiten Buckel ..... ;) Grüsse Gulp

OK ich rudere .... ;) Also klabüstern wir jetzt mal auf: Das SAN virtualisiert das Plattensubsystem und stellt dem Server eine Partition (quasi als Ersatz für die üblichen eingebauten Platte) zur Verfügung. Auf dieser Partition wird Windows installiert, pro Partion (also Installation/Kopie) eine Lizenz. Fällt Dir das Front-End (also die an das SAN angebundene Hardware) aus und Du klemmst dort neue an, brauchst Du keine Lizenz, die Installation/Kopie ändert sich ja nicht. Das wäre wie ein Mainboard+CPU Wechsel in einem Standalone Server ohne SAN und schlimmstenfalls must Du neu aktivieren, da sich die Hardware ID's ändern. Ich habe Deinen ersten Post aber eher so verstanden, ich fass es mal kurz zusammen: Du hast ein SAN und möchtest darauf N Windows Server Installationen machen und M weitere als ColdBackup. Das bedeutet letztlich Du benötigst auf dem SAN N+M Partitionen mit einer Windows Installation (dann brauchts wie beschrieben auch N+M Lizenzen). Jetzt alles klar? ;) Grüsse Gulp

@Jens: Du weisst was eine Partition ist? Grüsse Gulp

Falsch, Du wirst letztlich N+M mal installieren müssen (auch wenn Du zB die Partitionen clonst oder andere Methoden zur Kopie der Installation verwendest, aber auch das ist eine Installation/Kopie) und daher brauchst Du ohne SA und R2 eben für jede Installation/Kopie eine Lizenz. Grüsse Gulp

Microsoft lizensiert seine Betriebssysteme in der EULA schon länger nach Installationen oder Kopie, also ist der Startzustand letztlich wurscht, denn davon steht nix in der EULA. Die Ausnahmen von denen Du gehört haben willst sind meines Erachtens reiner Mythos ..... Wohlgemerkt können für Nichtbetriebssysteme (wie zB Serveranwendungen) andere Regeln gelten oder die Bedingungen der SA treffen zu. Die 4 virtuellen Lizenzen im R2 sind dem aufgekommenen Virtualisierungshype geschuldet und wurden mit R2 eingeführt und gelten daher nur für diesen. Grüsse Gulp

Wie lange hast Du denn gewartet? Das kann schon mal je nach verwendeter Hardware ein wenig dauern ..... ich kenne Fälle von 30-60 Minuten, anschliessend läufts meistens problemlos durch. Grüsse Gulp

Oha, Lob von höchster Stelle ..... ;) Tja, ich versuche eben aufzupassen und zu lernen ..... :cool: :D .... schliesslich kann Wissen nie verkehrt sein, oder? Grüsse Gulp

Du brauchst für jede Installation (gestartet oder nicht) eine eigene Lizenz, also N+M Lizenzen. Ausnahme ist der 2003 R2 da darfst Du 4 weitere virtuelle Installationen auf der Erstinstallation machen und betreiben, wenn die vituellen Installationen auf der physikalischen Installation laufen. Hast Du Software Assurance für Windows Serversysteme dann gilt: Cold Backups für die Wiederherstellung im Notfall (Disaster Recovery) Als Kunde mit Software Assurance für Microsoft-Serversoftware sowie für die zugehörigen CALs haben Sie Anspruch auf "Cold Backup"-Serverlizenzen für Wiederherstellungszwecke. Microsoft definiert einen Cold Server als einen Server, der bis zum Eintritt eines Notfalls ausgeschaltet ist. Der Server steht in keiner Produktiv-Umgebung und es findet keine Datenverarbeitung auf diesem Server statt. Läuft Software Assurance auf dem Produktionsserver aus, endet auch die Berechtigung für den Cold Backup-Server. Quelle: Software Assurance Services unter Enterprise Agreement Cold Backup kannst Du von Haus aus nur bei bestimmten Serveranwendungen zB SQL Server machen. Grüsse Gulp

Der einzig sicher funktionierende mir bekannte Weg ist eine Updateinstallation, Volumenlizenzen sind bei Microsoft Client Betriebssystemen grundsätzlich Updateversionen, die eine OEM, SB oder Retail Version als Lizenzgrundlage haben müssen. Da sich die Daten auf VL Datenträgern bei ein paar Dateien unterscheiden muss man zur reibungslosen Funktion eine Installation von einem VL Datenträger machen. Dies kann über eine Updateinstallation geschehen oder auch über eine Neuinstallation (der VL Datenträger unterstützt beide Wege). Der genannte Microsoft Key Changer kann zwar tatsächlich auch den Key zwischen verschiedenen Lizenzvarianten austauschen (zB von VL nach OEM oder SB nach VL) allerdings fehlen den Installationen dann die entsprechenden der Lizenz unterschiedlichen Versions Dateien (zB der Aktivierungsmechanismus). Der oobe Aufruf kann zB nur Lizenzen aus einem gleichen Nummernpool tauschen. Grüsse Gulp

Das funktioniert schon standardmässig in XP, jedoch nur bei eingeschalteter "schnellen Benutzerumschaltung" und der Anmeldung über die Willkommensseite. Diese wird allerdings bei XP nicht in einem Domänenumfeld unterstützt und automatisch deaktiviert beim Domänenbeitritt (und lässt sich auch nicht aktivieren). Ist die Willkommensseite aktiviert werden alle laufenden Programme eine angemeldeten Users und zB die Anzahl seiner neuen Mails in der Willkommensseite bei seinem Userbild angezeigt. In Vista gibt es keine klassische Anmeldung mehr, sondern nur noch die Willkommensseite (auch in Domänen), da funktioniert dies auch in einer Domäne. Einzige Vorraussetzung ist und bleibt, dass ein User angemeldet ist und Programme ausführt. Dienste und Anwendungen die von lokalen Systemaccounts gestartet wurden, werden hier zB nicht berücksichtigt und daher auch nicht angezeigt. Ist kein User angemeldet gibt es folglich auch nichts anzuzeigen. Grüsse Gulp

Hehe, ich sehe wir verstehen uns mal wieder blendend ...... :D :cool: ;) Grüsse Gulp

Ha jetzt weiss ich's wieder ..... (ich liebe alte Aufzeichnungen ..... ;) ) Ich hatte seinerzeit einen DNS Alias verwendet und dann in aller Ruhe das jetzige Script gebaut ........ Ist also doch nix mit automatischer Übernahme bei Namenswechsel ..... mein Gedächtnis lässt nach muss ich feststellen. Grüsse Gulp

Hach mein letzter PrintMig Umzug ist ein paar Tage her, ich meine jedenfalls, dass die User auch auf den neuen, anders benannten Printserver umgezogen sind (ich hatte auch damit gerechnet jedem User per Script seinen Drucker zuweisen zu müssen oder an jeden Client zu laufen, das war jedoch nicht notwendig). Mittlerweile ist mir das aber egal, da ich sowieso die Drucker per Script zuweise. Grüsse Gulp

Nope, sowohl die lokal installierten Drucker, deren Treiber, deren Anschlüsse, als auch die Freigaben der Drucker ziehen mit um und auch die User werden auf den neuen Printserver umgeleitet .... das geht wirklich so easy. Grüsse Gulp