Gulp

Hier kann auch noch eine Reparaturinstallation helfen, denn auch das geht in erstaunlich vielen Fällen nach einem Mainboard-Wechsel ohne Probleme. Also: Windows Setup CD einlegen, davon booten, Installation auswählen, jetzt sollte Setup ein vorhandenes Windows finden, dieses reparieren. Sollte vom Setup keine Windows Installation gefunden werden, kann es helfen (falls vorhanden und verwendet) die SATA/IDE/RAID Treiber beim Setup mit F6 einzubinden. Wird auch dann nichts gefunden, so wirst Du nicht um eine komplette Neuinstallation herumkommen. Greetz Gulp ** 2 Leute, ein Gedanke **

Im Boot Screen von Pro und Home steht nach der Installation nichts mehr ausser Windows XP und der Scroll-Balken ist danach auch bei der Home Edition blau. Die Einschränkungen der Home bleiben aber erhalten. Wie Microsoft immer so schön sagt: This behaviour is by design. Greetz Gulp

Hehe, ich hatte zwar vermutet, dass Du Mail Security meinst, aber geschrieben hast Du nur was von Symantec Corporate Edition - vielleicht sollte ich meine Kristallkugel auch mal wieder putzen ;-) ... beim lokalen Client hätte das Abschalten einen Sinn, beim Server würde ich es auch nicht machen. Greetz Gulp

Naja, eigentlich reicht es wenn ein deutsches Outlook nach dem Erstellen des neuen Postfaches noch vor dem Virenscanner ausgeführt wird. Dazu musst Du beim Erstzugriff die E-Mail Virenprüfung auschalten oder Dir Symantec Corporate in der deutschen Sprache zulegen. Bei der Verwendung von Outlook 2000 gibt es keine Möglichkeit, alle Namen nachträglich zu ändern, lediglich einige wenige lassen sich manuell umbenennen. Wie im Artikel erwähnt ist dies eine Einschränkung von Outlook 2000 und nicht von Exchange. Abhilfe schafft nur die Verwendung von Outlook XP/2003 oder ein alter Client für Exchange. Greetz Gulp

Zu dem von Dir beschriebenen Verhalten kommt es, wenn zum Beispiel ein SMTP Virenscanner (in englischer Sprache) auf die Postfächer zugreift, bevor Outlook (in deutscher Sprache) seinen Zugriff auf das Postfach durchführt. Die Ordnerstruktur in Exchange wird nämlich in Abhängigkeit der Sprachversion des 1. zugreifenden Clients lokalisiert. Dazu gibt es folgenden MS-KB Artikel: http://support.microsoft.com/default.aspx?scid=kb;en-us;188856 Also musst Du nur dafür sorgen, dass der Erstzugriff auf die Ordner nur mit einem deutschen Client durchgeführt werden. Änderungen an der Registry oder an anderen Stellen auf dem Server gibt es keine. Greetz Gulp

... also ich finde bei HP folgendes: http://h18023.www1.hp.com/support/files/server/us/locate/20_1122.html#30 und da sind doch Smart Array Treiber für Windows 2000 dabei! Gulp

Bei 2000 ist es F5 ... Schon mal einen NT Treiber versucht? Gulp

Der Treiber für den Controller muss beim Setup mit F6 eingebunden werden (sofern es Treiber für Windows 2000 gibt), ansonsten wird der Controller wohl nicht erkannt werden. Gulp

... ich mag ja vielleicht wirklich kleinkariert sein, nur macht es die Aussage von Dr.Melzer: noch immer nicht richtig, da Du jede Retail, OEM CD zu einer Corporate machen kannst. Gulp (der gerne das letzte Wort hat ;) )

Also für mich ist ein 'grundlegend anderes Produkt' etwas Anderes .... Die 10 unterschiedlichen Dateien, die die sogenannten Corporate Files genannt werden, beziehen sich lediglich auf die Lizenzschlüssel und die Aktivierung, daher sind weder grundlegend andere Funktionen möglich, noch werden grundlegend andere Features implementiert. Da man die Aktivierung auch in OEM Versionen automatisieren kann, z.B. durch den Einsatz einer im PC Bios generierten Hardware ID und dies auch durch die grossen OEM Hersteller genutzt wird kann ich beim besten Willen kein 'grundlegend' anderes Produkt erkennen. Ich könnte jetzt auch tiefer in die Verwendung und die tatsächliche Bedeutung der Corporate Files einschwenken, aber man muss ja nicht noch den Missbrauch von Corporate Versionen unterstützen. Auch bei den Service Packs macht es keinen Unterschied, ob ich eine Retail, OEM oder Volume License als Unterbau verwende, also wieso sollte es grundlegend anderes Produkt sein. Dass ein Unterschied vorliegt, (und sei es jetzt der von Retail zu OEM, dass nicht Microsoft für OEM, sondern der Händler kostenfreien Support leistet) dürfte klar sein, denn sonst käme es nicht zu dem beschriebenen Problem. Daher kann ich Deinen Vorwurf, meine Antwort ginge an der Frage vorbei, immer noch nicht ganz nachvollziehen. Gulp

Leider nicht, denn die Validierung des Keys erfolgt u.a. durch die geänderte setupp.ini, die u.a. Bestandteil der Corporate Files ist. Übrigens, ein blosses ändern der setupp.ini auf die Werte der für Volumenlizenzen verwendeten Version bringt da z.B. auch nichts. Greetz Gulp

... und was ist an Deiner Antwort anders? *kopfschüttel* Gulp

Die Volume License CD's enthalten sogenannte Corporate Files, die unter anderem die Aktivierung ausschalten. Die herkömmlichen Retail oder OEM CD's nehmen aus Mangel an diesen Corporate Files keine Volume License Keys an. Greetz Gulp

Nimm die adminpak.msi aus dem Service Pack, die von der CD kann man nur ohne Service Pack installieren (es sei denn Du integrierst das SP in die CD). Genauso verhält es sich mit der Wiederherstellungskonsole. Greetz Gulp

Sysprep ändert unter anderm auch die SID, ist nur nicht so komfortabel wie NewSID .... Greetz Gulp

NewSid von http://www.sysinternals.com erledigt das .... Greetz Gulp

...oder so, thanks! Gulp

Da würde TweakUI (von Microsoft höchstpersönlich) empfehlen. Einfach mal im Downloadcenter nach Powertoys suchen (in englisch). Greetz Gulp

Da musst Du in den lokalen Sicherheitsrichtlinien folgenden Eintrag setzen (falls Du keine DomainPolicies verwendest, ansonsten musst Du das dort ändern): Unter Start, Ausführen gpedit.msc starten: Computerkonfiguration --> Administrative Vorlagen --> System --> Benutzerprofile: Eigentümer von servergespeicherten Profilen nicht prüfen = aktiviert Sollte anschliessend funzen ... Greetz Gulp

Geht aber doch mit TweakUI von Microsoft, denn da kannst Du auch Domain User angeben. Allerdings entspricht das leider nicht den Anforderungen von marci, da dies nur generell eingestellt werden kann und auch generell automatisch den dort eingestellten User einloggt. Greetz Gulp

Zum Aufdröseln der Systemprozesse hilft der ProcessExplorer von Sysinternals ... Look at SYSINTERNALS Greetz Gulp

Spannend? Ja, tatsächlich und ich muss echt sagen ich hab's auch noch genossen. Mit Kollege Velius kann man offensichtlich auch trefflich diskutieren. Die Geschichte um die SID und wo diese kleinen possierlichen Tierchen (um es mit Grizmek's Worten zu sagen)überall auftauchen, ist auch nicht ganz so einfach, wie man es immer glauben möchte. Wie man sieht hat sich Velius die Mühe gemacht und sogar dafür ein eigenes Testscenario aufgebaut. Da ziehe ich Mal meinen Hut .... Dennoch macht es klar, dass die Computer-SID's keineswegs ignoriert werden sollte. Schliesslich gibt es immer wieder Anwendungsfälle in denen duplizierte Computer-SID's auftauchen (können) und sich nicht unbedingt zwingend an einer Domäne anmelden müssen, auch wenn die Computer Teil der Domäne sind. Und ja, ich kann Velius bestätigen, die SID des im AD abgelegten Computerkontos besteht aus der lokalen Computer-SID und eines Teils der Domänen-SID. Erstaunlicherweise kommt es bei duplizierten Computern aber nicht immer zu dem von Velius beschriebenen Problem, da ich auch schon in einer NT Domäne "erfolgreich" zwei geclonte Workstation gleichzeitig angemeldet hatte. Bei Windows 2000 und 2003 scheinen mir allerdings Velius' Versuchsergebnisse (wohl wegen der konsequenteren Verwendung von SID , RID und der gesteigerten Objektmöglichkeiten im ADS selbst) ohne Ausnahme zuzutreffen, denn da konnte ich bisher nur die geichen Ergebnisse erzielen wie Velius. Aprospos StarWars ..... da freue ich mich auch schon drauf! Greetz Gulp

Ob Schwachsin oder nicht .. ;-) Es ist ein Sicherheitsrisiko und kann tatsächlich zu Problemen führen, denn das habe ich schon mehrfach am eigenen Leib erfahren dürfen. Ich denke Du hast meinen Gedankengang noch nicht ganz "gefressen". Also Built-In-Accounts haben, wie Du richtig bemerkt hast alle die gleichen Benutzer-SID's. Maschinen-SID's sind verschieden (normalerweise, bei nicht geclonten Workstations). Die Kombination Benutzer+Maschinen-SID ergibt bei lokalen Zugriffen (standardmässig in einer Workgroup, dennoch möglich in einer Domain) grob gesagt die Berechtigung auf die Daten oder das Token. Sind die Maschine-SID's alle gleich, die Built-In Accounts sinds ja auch hast Du - Bingo - mit einem einzigen Useraccount Zugriff auf alle SID-Duplikate. Na, und das soll in einer Domain keine Rolle spielen? Ich gebe zu, dass es nicht ganz so einfach ist, aber ein Leck ist es allemal! Greetz Gulp PS: .... und in Deinem Link steht es ja auch ganz klar: The problem with cloning is that it is only supported by Microsoft in a very limited sense. Microsoft has stated that cloning systems is only supported if it is done before the GUI portion of Windows Setup has been reached. When the install reaches this point the computer is assigned a name and a unique computer SID. If a system is cloned after this step the cloned machines will all have identical computer SIDs. Note that just changing the computer name or adding the computer to a different domain does not change the computer SID. Changing the name or domain only changes the domain SID if the computer was previously associated with a domain.

Hehe, schon ... aber mein Einwand ist durchaus richtig ... denn das Problem ist eben nicht von einer Domain abhängig, es tritt dort nur weniger zu Tage. Consequences of duplicate SIDs in a domain environment If you had the same 500 disk-imaged desktop computers running in a domain model, all with the same SID, the impact is significantly lessened. All users are logging into a domain and are being assigned a domain-based user SID. This SID is, by nature of the domain model, guaranteed to be unique and can be used to secure files and resources within the network. The Security Account Manager has no problems distinguishing users because they are coming from a common, centralized domain security database and all processes and tokens are running within each user's security context. Note You will still have local security issues when dealing with local machine accounts (administrator, guest, etc.) as outlined above. Also tut man durchaus gut daran die SID zu ändern ... und genau das war mein Einwand.

.... ich frag mich wirklich, ob ich hebräisch schreibe. Wieso glaubst Du hebe ich eigentlich immer das Wort LOKAL hervor? Lokal ist lokal und nicht Domain! Ist es wirklich so schwer zu begreifen? Ich habe nicht die Domain SID's im Blick sondern die LOKALEN auf der Workstation. Diese SID (und ja die haben eine - zufällig generiert beim Setup) ist bei geclonten Rechnern identisch. Da in einer Domain diese SID NICHT für Prozess Tokens und Trust Relationships herangezogen wird, sondern die SID des im ADS gespeicherten Objetktes (User/Gruppe/Machine Account), kommt das Problem nur selten zu Tage. Habe ich vorm Clonen der Workstation Useraccounts LOKAL erstellt können diese User untereinander auf Daten der geclonten Workstations zugreifen, da ihre lokale SID identisch ist. Genau das ist das entscheidende Problem. Wären die Benutzer auf verschiedenen Systemen erstellt worden, so wäre das nicht möglich, da sich deren SID unterscheidet. Natürlich misslingt ein solches Szenario auch nach einer Änderung des Passwortes des Users TEST auf einer der geclonten Maschinen. So ... jetzt alle Unklarheiten beseitigt? Greetz Gulp