Gulp

Das kann ja nur funktionieren, wenn der private User-/Anmeldename mit dem auf dem Server übereinstimmt und genau das ist das Problem. Ändere den Usernamen auf dem Server oder gib dem Mitarbeiter einen neuen User und deaktiviere den alten, dann muss der User immer seine Anmeldedaten eingeben. [edit] oder IThome's Vorschlag ist des Pudel's Kern ..... [/edit] Grüsse Gulp

Nichts, die aus XP/2000/NT bekannte Anmeldemaske gibt es nicht mehr in Vista. Grüsse Gulp

Als Microsoft Tool fällt mir für Win98/NT/2000 eigentlich nur Microsoft's NetMeeting und die dort aktivierbare Desktopfreigabe auf, damit kann man auch einen Client fernsteuern und administrieren. Allerdings hat das jedenfalls wenn ich mich recht entsinne nichts mit RDP zu tun, sondern NetMeeting verwendet ein eigenes Protokoll. Über RDP gibt es ohne Drittanbieter Tools keine mir bekannte Möglichkeit Clients ausser XP per Remotedesktop zu verwalten. Grüsse Gulp

Problematisch sind bei einem solchen Szenario eventuelle Änderungen am 2. DC, da reicht es wenn sich zB das Passwort eines Computerkontos ändert und dann nach dem Image die USN Synchroniserung den Bach runter geht. Wenn auch der 2. DC während der Image Erstellung heruntergefahren ist, kann das Vorhaben funktionieren, oder aber Du machst vorher eine Sicherung des Systemstate und bootest den 1. DC nach dem Aufspielen des Images mit F8 und der Bootoption "Verzeichnisdienste wiederherstellen" und stellst das AD aus dem Systemstate (wie zB hier beschrieben: faq-o-matic.net: Wie stelle ich das AD wieder her? wieder her. Ne Funktions-Garantie gibt's für das einfache Rücksichern eines Images aber nicht! Grüsse Gulp

Wieso sollte ein Zugriff auf das Netzwerk vom verwendeten Filesystem abhängig sein? Macht doch gar keinen Sinn, zumal ich auf einem Linux Server mit EFS auch von einem Windows Rechner transparent Daten ändern kann. Der Zugriff vom Netz wird sowohl vom Mac als auch vom Windows Rechner über SMB abgewickelt, welches alle Anfragen an das jeweilige Filesystem übergibt, davon welches Filesystem die SMB Freigabe tatsächlich unter sich hat bekommt der Client überhaupt nichts mit (muss er auch gar nicht wissen, er kommuniziert ja übers Netzwerkprotokoll und nicht per lokalem Filesystemtreiber). Solange die Rechte auf der Share stimmen, sehe ich erstmal keinen Grund der das Filesystem betrifft, weshalb auch ein schreibender Zugriff direkt auf der Share fehlschlagen sollte. Welche Excel Version inkl. Service Release setzt denn der betreffende Windows Client ein, der die für Mac's unlesbaren Excel Dateien produziert? Grüsse Gulp

Man kann versuchen einen eventuell vorhandenen Memory Dump in den Microsoft Debugging Tools zu laden, um den Verursacher zu ermitteln. Allerdings deutet ein 0x000000B4 ziemlich eindeutig auf die Grafikkarte bzw deren Treiber hin, mit der Zeitumstellung würde ich das erstmal nicht in Zusammenhang bringen. Es gibt aber für die Sommer/Winterzeitumstellung auch den einen oder anderen Hotfix, ausserdem sollte man mal versichen nacheinander die jetzt durch die Rücksicherung noch fehlenden Hotfixes zu installieren. Weiterhin kann nicht schaden auf aktuelle Firmware/BIOS der Controller, Mainboard etc. zu prüfen und ggfs zu installieren. Grüsse 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