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

Und wieso verliert dann z.B. der LOKALE Admin nicht seine Zugriffsrechte auf der Machine, wenn der Rechner in die Domain geschoben wird? Seine SID ist nicht in der Domain gespeichert, die SID wird nicht geändert. Dennoch behält er alle Verwaltungfunktionen des LOKALEN Rechners. Wo speichern denn DC's die SID's der Objekte? Doch in der ADS ... und nicht auf dem zu dem Objekt gehörigen Rechner. Selbst die domänenrelevanten Teile der Registry werden doch, salopp gesagt, nur über die lokale Registry geladen (die lokale wird keinesfalls ersetzt). Wo sollen denn nach Deiner Meinung die Kennwörter der LOKALEN User und Gruppen gespeichert sein, wenn die lokale Workstation nichts mit SID's am Hut hat. Ich für meinen Teil meinte und meine immer noch die LOCALE WORKSTATION SID, die hat mit der Domain, den Betriebsmasterrollen und dem RID-Master so ziemlich gar nichts am Hut. Aus Deiner Argumentation folgere ich lediglich, dass ich mich um lokale SID's anscheinend nicht kümmern muss, da es ja anscheinend keine gibt. Objekte wie neue lokale Benutzer und Gruppen kann ich ja eh nicht anlegen, da meine XP Pro ja kein RID-Master sein kann. Na herzlichen Glückwunsch ... Trotzdem ... freundliche Greetz! Gulp P.S. Sicher gibt es für eine Workstation einen Computer Account und ja dieser hat auch eine unique SID, der bei dem Domänenbeitritt generiert wird. Dennoch wird dieser Account nicht auf der LOKALEN Workstation hinterlegt, sondern im ADS, genauso wie ein Domänen-USER und genau da ist doch der Hase begraben. Die Domain-SID hat nichts mit den lokalen SID's der Workstations am Hut.

@Velius: Wer lesen kann ist klar im Vorteil ;-) : .. Whenever a domain controller ..... it assigns THE OBJECT .... Hier ist das Objekt in der SAM/ADS gemeint und das hat tatsächlich eine unique SID. Die Local Workstation SID tangiert das allerdings überhaupt nicht, richtest Du nämlich einen lokalen Benutzer ein, so hat dieser keinen Domänenanteil in seiner SID sondern nur den Deiner Maschine. Daher spielt es sehr wohl eine, wenn auch untergeordnete, Rolle, ob man die SID's ändert oder nicht. Die einzige Ausnahme sind die Domain Controller selbst, denn die ändern tatsächlich ihre SID, deshalb sollst Du laut MS auch niemals einen DC mit bereits installiertem ADS (oder bei NT der SAM) clonen. Ausserdem ... Deine angeführten Websites erzählen nur was von Rollen (beträfe nur DC's ) oder User/Gruppen, bei meiner Site ist ein explizites Beispiel der Local Workstation SID in einer Domain aufgeführt. Greetz Gulp

@Velius: Ist leider nicht ganz richtig, denn die eigentlichen Rechner-SID (Local Workstation SID) wird nicht geändert, lediglich die User-SID wird für die Anmeldung und das relevante Security Token und die Trust Relationships verwendet. Auszug aus http://www.microsoft.com/technet/archive/ntwrkstn/deploy/depopt/cloning.mspx Note: If two workstations have the same primary SID and are participating in workgroup/local authentication security, the first user account generated (and so forth) on each workstation is the same because the SID on both computers is the same. See "Consequences of Duplicate SIDs in a Workgroup Environment" for an example. More information: MS TechNet : 162001 ..... Consequences of duplicate SIDs in a workgroup environment If a company has 500 cloned desktop computers—all with the same SID—running in a workgroup/peer-to-peer model, significant security challenges arise. Each workstation would have no way of differentiating a local account from a remote account. Restrictive access to secured files and directories through SID certification would be impossible, and tokens being used would all contain the same SID. The entire security structure based on SIDs and access tokens would be compromised. For more information see MS TechNet : 163846 Example: \\WS1 and \\WS2 are two workstations at Netwerks Corporation. Deployed using a binary disk image–copying program, these workstations have duplicate security identifiers. Eric on \\WS1 has a local machine account on WS1 of S-1-5-21-191058668-193157475-1542849698-1000. Stephanie on \\WS1 has a local machine account on WS2 of S-1-5-21-191058668-193157475-1542849698-1000. Eric is performing employee performance reviews and saving his information to C:\Data\Reviews on his local NTFS drive. He uses Windows NT Explorer to share the directory and to set the security rights so that he is the owner and only he has rights to access the files. Stephanie is logged onto \\WS2 and is browsing the network using Network Neighborhood. She recognizes \\WS1 as Eric's machine and attempts to connect to a Reviews share that Eric created. She is given complete control over the contents because her SID (S-1-5-21-191058668-193157475-1542849698-1000) is identical to Eric's (S-1-5-21-191058668-193157475-1542849698-1000). As one can see, there is no way to differentiate WS1\Eric from WS2\Stephanie because the SIDs are identical. Taking this to the next logical step, any data stored on removable media that are formatted using a secure NTFS scheme is no longer secure. Because duplicate SIDs exist, there is no way to completely secure sensitive data in an environment of binary duplicated machines that share an identical SID. 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. Greetz Gulp

Ja ist es, dazu gibts das CMD Tools ldifde (Microsoft KB Artikel 237677) . Allerdings erfordert das in den meisten Fällen eine Anpassung der exportierten Daten. Greetz Gulp

Guck mal auf SYSINTERNALS, die haben recht gute (und freie) Tools zum Monitoring und mehr .... das was Du hier suchst ist RegMon ... Greetz Gulp

Da gibt's auch von sysinternals was kostenloses (NewSID), funzt einwandfrei und ist recht bequem zu bedienen. Look HERE Greetz Gulp

GFI MailEssentials (guckst Du HIER ) kannst Du gleichzeitig als AntiSpam Suite verwenden. Greetz Gulp

Also ich habe erfolgreich 8 Server (win2k und win2k3) mit RemoteAgents, darunter 3 DC's (auch über RemoteAgents) auf einen Backup-Server an dem eine TapeLibrary hängt per IDR gesichert und getestet. Funktioniert prima und ist kaum zu ersetzen. Wenn man Data1701's Ratschläge befolgt ist's echt easy. Ich finde es deutlich schneller, da die OS Partition des 1. DC nach 20 Min voll funktionsfähig zurückgesichert war. Die Wiederherstellungszeit hängt natürlich auch von den verwendeten Partitionsgrössen ab, aber ich spare mir 20-30 Minuten für eine rudimentäre OS Installation + 15 Minuten Installation Backup-SW . Daher denke ich schon, dass es vorteilhaft ist IDR einzusetzen. Muss ja auch nicht bei allen Servern sein. Greetz Gulp

RAID 5? Da würde ich aber abraten oder mal mit ServerMagic probieren. Allerdings gibt's keine Garantie auf Erfolg. Greetz Gulp

Der normale 2003 Server hat ein Problem mit dem Beenden von Exchange 2003 Diensten (gibt's was in der KB dazu: MS KB Article ). Greetz Gulp

Du kannst nicht vom Band booten, sondern verwendest dazu die Disketten bzw die CD (sofern Du das *.iso auch gebrannt hast ;-) ). Ich habe das mal getestet (allerdings noch mit der 9er) und es funktioniert erstaunlich gut, Diskette/CD zum Boot (bei den Disketten brauchst Du allerdings noch eine OS-CD), Verbindung zum Backup-Server wird hergestellt (sogar übers Netz, wenn Du mit RemoteAgents sicherst), Band auswählen und je nach Grösse Deiner OS-Partition (bei 8 GB brauchte es bei mir ca 20min) bist Du relativ schnell wieder voll einsatzfähig. Greetz Gulp