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*

Hallo,

wenn du eine komplett neue Dom aufsetzt, so habe ich das verstanden, dann kanns du die alten BDC auch nicht in die neue Dom übernehmen.

Das war bildlich zu verstehen; das sollte den Unterschied zwischen native & mixed verdeutlichen...

Aber eine Vertrauensstellung zwischen den beiden Dom´s, das geht.

Mit Memberservern muß man aufpassen, weil viele Dienste sich über einen Dom.User anmelden.

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....)

Der Neue muß dann auch die richtigen Berechtigungen erhalten, ist ziemlich viel Arbeit das alles anzupassen.

Des wegen ist die Vertrauensstellung, denke ich, der bessere Weg.

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):

In a domain, Windows NT/2000 does not allow two computers having the same SIDs to log on to the domain. In addition, Windows 2000 domains rely more heavily on the SID as a unique token for administering and controlling security than Windows NT 4 domains, which base security access on domain user names and passwords.

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:

Wenn Sie jedoch beide Computer in derselben Domäne oder Arbeitsgruppe verwenden wollen, kann immer nur einer der Computer angemeldet sein, sofern Sie nicht die Identifizierung von einem der beiden Computer ändern, bevor Sie versuchen, den Computer in der Domäne anzumelden. In den folgenden Abschnitten wird erläutert, wie Sie die Identifizierung des Zielcomputers ändern können.

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

NewSID

NewSID is a program we developed to change a computer's SID

http://www.microsoft.com/technet/archive/ntwrkstn/deploy/depopt/cloning.mspx

The System Preparation tool will modify the initial Unique SID section but will not traverse the SAM and change all of the user accounts' SID prefixes to match the new SID. Account Unknown errors will be generated, and the administrator will need to recreate all user accounts again. The System Preparation tool will not traverse an NTFS partition to modify file permissions with the new SID information.

Und mit lokalen, built-in Konten auf Ressourcen auf anderen, geklonten Rechnern in einer Domäne zu zu greiffen ist doch schwachsinn, oder?

Der schnellste Weg wäre natürlich wenn ich die Festplatte clonen würde sie wieder in den zweiten Pc einbaue Computername und Useranmeldung ändere und in dann ins Netz hänge, aber funktioniert das auch, gibt es da nicht Probelme mit einer ID, oder wie kann ich das noch lösen.

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:

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.

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:

Duplicate SIDs aren't an issue in a Domain-based environment since domain accounts have SID's based on the Domain SID. But, according to Microsoft Knowledge Base article Q162001, "Do Not Disk Duplicate Installed Versions of Windows NT", in a Workgroup environment security is based on local account SIDs. Thus, if two computers have users with the same SID, the Workgroup will not be able to distinguish between the users. All resources, including files and Registry keys, that one user has access to, the other will as well.

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:

What exactly is a SID?

 

A user or group account includes a security identifier (SID), a unique number that identifies the account. 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

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

 

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.

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/9a353810-8e3a-4023-a557-db1a686d8ec8.mspx

RID master

Whenever a domain controller creates a user, group, or computer object, it assigns the object a unique security ID (SID). The SID consists of a domain SID, which is the same for all SIDs created in the domain, and a RID, which is unique for each SID created in the domain.

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

Ich weiß das das nicht so toll ist würde aber gerne wissen ob ich DC accounts als authentifiezierung für den isa nehmen kann.

 

 

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?

Movie Record and Playback

Workstation 5 offers the ability to record your actions within a virtual machine and save the movie in an .AVI format, facilitating team collaboration. Replay the resulting .AVI file on any PC equipped with an .AVI player. A free Windows player is available for download from the VMware web site. See Screen Shot Capture.

Record steps to reproduce defects in a particular configuration, or record configuration steps prior to running an application. Share the movie with colleagues to enable team collaboration. See Movie Capture.

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

.

Der schnellste Weg wäre natürlich wenn ich die Festplatte clonen würde sie wieder in den zweiten Pc einbaue Computername und Useranmeldung ändere und in dann ins Netz hänge, aber funktioniert das auch, gibt es da nicht Probelme mit einer ID, oder wie kann ich das noch lösen.

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