Velius

Schon schräg die Typen... Wenn man bei Sony Ericsson nachschauen geht, dann landet man nur bei diesem Tool: Ericsson Mobile Organizer (EMO) 5.0 Aber lädt man das Teil runter ist da der Smartner Duality Professional drin.... Aber Thanks @Mycroft2K

@Bitfox Hast wohl noch in einem anderen Forum gepostet, was?.... ;) Gruss Velius

@Mycroft2K Coole Sache das, eigentlich genau das was wir brauchen, nur leider steht da überall: ---------------------------------------------- Windows Mobile and Sony Ericsson Clients are not available through your operator at this stage. Please follow this link to Handango to purchase your Smartner Duality for these devices. ---------------------------------------------- Am Anfang dachte ich, dass wäre eine Schweizer Krankheit, aber so wie es aussieht steht das fast überall. Any clues?? :( Gruss Velius EDIT: Man folge dem Link....http://www.handango.com/PlatformProductDetail.jsp?siteId=1&productId=121869&productName=Smartner+Duality&programId=45&sectionId=0&productType=2&postingData=true&optionId=1_11_2&jid=4ECDFF8687F62XADB88FF7DXD816FFBD&platformId=11&features=0&advSearch=true&affiliateId=758&catalog=110&pc=list%5B2%5D_title *patsch*

Das war bildlich zu verstehen; das sollte den Unterschied zwischen native & mixed verdeutlichen... Das hat aber nicht mit mixed oder native zu tun. Wenn man mit ADMT arbeitet wird genau dieser Zustand vermieden, wenn man dabei auf die Reihenfolge achtet (User, Computer, Memeberserver....) Den versteh ich jetzt nicht? Die einize Migration die ohne Vertauanesstellungen klar kommt ist die in-place, und die will er ja nicht... Gruss Velius

Vielleicht hilft dir das auch weiter: http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/deploy/dgbf_upg_lsno.asp http://support.microsoft.com/default.aspx?scid=kb;en-us;240305 Gruss Velius

Tatsache ist, du kannst alle NT 4.0 Server noch im Native Mode fahren, nur kann leider keiner der BDC's (PDC geht nicht, denn das ist auch in einer AD Domäne "nur" einer, und zwar der PDC Emulator) mehr mit der Benutzer Datenbank synchronisieren. Oder anders ausgedrückt, deine NT 4.0 BDC's werden nutzlos. Memberserver sind allerdings kein Problem (wir haben hier auch noch welche, trotz native Mode). Gruss Velius

Kleine Frage: Wieso schaltet ihr dann die Ziel-Domäne nicht in den native Mode? Eigentlich gibt es nichts was dagegen spricht....

Hi Das Problem ist, dass kein Migrations Tool den Wert für SID_history im Ad anlegen kann, wenn AD nicht im Native Mode ist. http://www.mcseboard.de/showpost.php?p=294096&postcount=24 Das Attribut ist dafür da, die SID die in der NT 4.0 Domäne verwendet wurde in der neuen Domäne "anzuhängen", so dass der Zugriff auf nicht migrierte Ressourcen bestehen bleibt, solange nicht die ganze Migration abgeschlossen ist. Wie gesagt, kein Native Mode = keine SID_history..... :( :wink2: Gruss Velius

Hi Die sind nicht dynamisch, jedenfalls nicht die Zielports. Die Quellports sind meistens dynamisch. Wenn du da genau hinsiehst, denn wirst du bemerken, dass er immer auf dem Port 139 hört, und 139 bedeutet NetBios Session Service und wird im Zusammenhang mit Windows Fileservices verwendet. Wenn der Rechner alle Verbindungen zu Fileservices trennt, oder neu gestartet wird, dann müssten die eigentlich weg sein. Gruss Velius P.S.: Kann gut sein, dass einige immer da sein werden....

Ja, das stimmt, denn ich war auch der Meinung, dass ich schon erfolgreich zwei geklonte Rechner (nicht mit SID changer Tool bearbeitet) an der selben Domäne hatte. Bei Symantec steht das so (aber nur auf Englisch): Gruss Velius P.S.: So'ne grosse Mühe war's gar nicht; nur mal kurz zwei Rechner auseinander genommen.... :schreck: :p

Alles ****sinn :( (Wieso reden die auch immer so um den heissen Brei....??) Ich hab's nachgestellt, und habe micht durch die Aussage "Every user account and workstation or server running Windows NT on your network is issued a unique SID when the account is first created or the computer joins a domain" irritieren lassen. Scheinbar übernimmt AD die Computer SID, und hängt noch die RID dran oder so. Folgende Aussage trifft es am besten: Einführung in das Duplizieren eines Windows NT-, Windows 2000- oder Windows XP-Computers Folgendes habe ich versucht: Zweite HDD in einen Rechner und ein disk-to-disk Image mit Ghost. Die zweite HDD habe ich dann wieder in den ursprünglichen Computer gepackt. Anschliessend habe ich mich versucht mir beiden Rechnern an der Domäne anzumelden. Fehlanzeige, es geht nicht, denn es gibt nur ein Computerkonto für beide Rechner. Einer der beiden hatte immer Probleme wie "Computerkonto existiert nicht" usw. Na ja, damals mit Ghost Corporate habe ich scheinbar ohne gross nachzudenken noch den Ghostwalker drüber rasseln lassen.... Fazit: Es braucht irgend ein Tool, entweder Sysprep, NewSID, oder Ghostwalker oder wie sie alle heissen. Allerdings wird damit nur die SID des Computers angepasst. Grüsse Velius

Ich kann jetzt nicht nachweislich wiederlegen, dass die lokale SID eines Rechners beim Beitretten einer Domäne nicht, sondern "nur" im AD angepasst wird, aber dein Einwand hat trotzdem keine Relevanz, da du egal welchen SID changer du einsetzen wirst, die SID der lokalen Benutzer Konten nicht ändern kannst: http://www.sysinternals.com/ntw2k/source/newsid.shtml http://www.microsoft.com/technet/archive/ntwrkstn/deploy/depopt/cloning.mspx Und mit lokalen, built-in Konten auf Ressourcen auf anderen, geklonten Rechnern in einer Domäne zu zu greiffen ist doch schwachsinn, oder?

Deine Argumentation ist akzeptiert, nur spricht der TO von Netz. Ich schliesse daraus eine Domain, und ich habe schon im allerersten Thread meinerseits von einer Domain gesprochen: Dann kam erst dein Einwand, welcher für eine Domain nicht richtig ist. Wenn wir von einer Workgroup sprechen, dann kommt's natürlich zu den von dir genannten Problemen. Na? Ist jetzt alles klar?? ;) EDIT: http://www.sysinternals.com/ntw2k/source/newsid.shtml

Du kannst ja mit deinem XP auch nicht deiner XP Domain beitretten, oder? Wenn du den zweiten Link, und deinen eigenen aufmerksam gelesen hättest, dann wäre dir aufgefallen, dass sogenannte built-in accounts immer die gleiche SID haben. Deswegen gibt es auch in einer Domäne eine Information mehr, nähmlich der Domänen Teil der SID. Somit ist es dem AD möglich, unter den verschiedenen Domain Admins beispielsweise zu unterscheiden, denn andernfalls hätten alle in dieser Gruppe in allen Domänen die gleichen Rechte. Nur nochmals zu Klärung: Standartmäsig hat ein ein Mitglied der Gruppe "Domain Admins" das gleiche Rechte, wie ein anderes Mitglied dieser Gruppe in einer anderen Domain. Allerdings, wenn man dieser Gruppe ein recht Verwehrt, oder explizit erteilt, auf NTFS beispielsweise, dann wird das nicht automatisch auf alle Domänen Admins einer Organisation übertragen, sondern nur dieser einen. Na, ist jetzt alles klar? Wenn du mir nicht glaubst, dann kannst du auch gerne hier unter Well-known SID´s nachsehen gehen. Wie sich das Verhalten auf einen lokalen nicht built-in Benutzer auswirkt, wenn der Rechner einer Domäne beitritt kann ich jetzt nicht genau sagen, spielt aber inerhalb einer Domäne keine Rolle da in Domänen in der Regel nicht mit lokalen Benutzern (also in der lokalen SAM das Computers) gearbeitet wird.

äh hallo?? Ich glaube, du kannst nicht lesen..... Der Satz lautet: Whenever a domain controller creates a user, group, or computer object, it assigns the object a unique security ID (SID) ...was sinngemäs soviel bedeutet wie, dass wenn ein Objekt in einer Domäne erstellt wird, dieses eine eindeutige SID bekommt. Das "whenver a domain controller...." sollte darauf hinweisen, dass nur Controller Objekte erstellen können, Server Computer und Benutzer schon gar nicht. Benutzer können das Recht haben, diesen Prozess auszulösen, aber ausgeführt wird das auf dem Controller. Darum kannst du auch keine Objekte hinzufügen, wenn der RID-Pool erschöpft und der RID-Master nicht da ist. (Deswegen auch meine Links). Ausserdem bindet AD/NTFS noch einiges mehr als blos die Zugriffsrechte an die SID. Bestes Besipiel: Computerpasswörter. Was meinst du, wie AD die Computerpasswörter managet? Und sag jetzt nicht über WINS/DNS, denn das sind Namensauflösungs Mechanismen.... Aber was soll's, du wirst eh an deine Version glauben..... :rolleyes: :rolleyes: P.S.: Deine Links sollten den Vorgang für User SID verdeutlichen, erwähnen aber nicht das praktische Verhalten von gleichen Computer SID's in einer Domäne. P.P.S.: Aus deinem eigenen Link:

Bei Fragen wie eine SID auf gebaut ist, oder was daran der Domänen-, und was der Objektteil ist, siehe hier: http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsce_ctl_xgqv.asp Grüsse Velius

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/9a353810-8e3a-4023-a557-db1a686d8ec8.mspx Was bitte ist daran nicht richtig? :wink2: Gruss Velius P.S.: Den Rechner einer Domäne beitretten lassen hat im Übrigen den selben Effekt, wie das Konto im AD erstellen!

Hi Vielleicht verschaft diese Seiote einen besseren Eindruck darüber, welchen Virenscanner du anschaffen solltest: http://www.av-comparatives.org/ Gruss Velius

Das geht, und zwar mit RADIUS: http://www.mcseboard.de/showpost.php?p=346550&postcount=3 Der ISA muss dabei nicht Member der Domain sein. Gruss Velius

Wie wär's mit VMware 5? http://www.vmware.com/support/ws5/doc/whatsnew_ws.html Grüsse Velius

@Blub Beim Export jedenfalls ist das Stoppen des Dienstes nicht nötig, beim Import ist das aber sehr wahrscheinlich, da die Konfiguration geladen werden muss. @carlito Die DB ist beim DHCP sehr nebensächlich. Das wichtigste am DHCP ist die Konfiguration. Die Idee ist ja, einen Server für den Fall bereit zu halten, das der aktive DHCP abraucht. Den Ersatzserver kann man dann einfach anmachen und die Konfiguration Importieren, oder das bereits schon vorher wenn die original Konfig. sich nicht all zu oft ändert. Addressen können ja logischerweie noch keine Vergeben sein auf dem neuen DHCP, und der Client versucht standartmäsig immer die bisherige IP zu erneuern. Gruss Velius

Sowieso ist keiner auf die eigentliche Frage eingegangen.... Du brauchst kein Tool, um einen geklonten Rechner in eine Domäne aufzunehmen, denn jeder Rechner erhält bei der Aufnahme in eine Domäne eine neue SID. Probleme gibt's nur, wenn du eine PC der bereits Mitglied einer Domäne ist duplizierst. Gruss Velius

Hi Deine Internetsecurity macht nichts weiter, als die Verbeitung einer der Sasser Varianten zu unterdrücken. Auf meiner FW sieht das Log etwa so aus: 1,[16/Apr/2005 12:38:37] Rule 'All other Ports': Blocked: In TCP, [i][color=red]IP des infizierten Rechners[/i][/color]:1794->localhost:[i][color=red]445[/i][/color], Owner: no owner Leider wird das auch bei mir immer noch geloggt, was dauf hindeutet, dass es immer noch etliche Rechner gibt, welche durch Sasser infiziert sind. Wenn die Rechner gepatcht sind, richtet es zwar keinen Schaden an, trotzdem versucht sich der Virus über die Internetverbindung des Rechners weiter zu verbreiten. Du kannst das nur über die Internetsecurity unterdrücken, dass da nicht ständig ein Pop-up auftaucht sobald wieder Päckchen geblockt wird. Schau mal im Manual nach. ;) Gruss Velius

Bei uns hat das so geklappt, allerdings haben wir einen Notes Client auf dem EX installiert, damit der Wizard überhaupt mit dem Domino connecten konnte. Es ist durchaus möglich, dass es eine bessere Variante gibt, da es nicht wirklich schick ist, auf dem EX eine Cleint Software wie Lotus Notes zu installieren. Aber vielleicht hilft's. Gruss Velius P.S.: Unser EX läuft trotz Notes sauber :p ;)

Seit W2K3 Server stehen dem Dienstprogramm netsh.exe auch zwei neue Parameter zur Verfügung, welche der Exportieren und Importieren des DHCP Konfiguration erleichtern: Verwenden des Dienstprogramms "Netsh" zum Exportieren und Importieren von DHCP-Bereichen Gruss Velius