Jump to content

frr

Members
  • Gesamte Inhalte

    223
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von frr

  1. Hallo Johannes,

     

    das Windows ist dafür nicht zu ****e;-). Das liegt an dem StrictNameChecking, was Du deaktivieren musst. Dann klappts auch mit dem Aliasnamen:

     

    Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name

     

    Allerdings solltest Du keinen Aliasnamen verwenden, sondern A Einträge. Dadurch kannst Du durch die Netzwerkmaskenanforderung des DNS Servers sicherstellen, dass der Client auf dem nächstgelegenen Server landet.

     

    Die Goldkörnchenlösung wäre allerdings DFS. Viel besser wäre es, wenn Du das gute Installpaket auf einen DFS Stamm legst. Dadurch musst Du Dir auch keine Gedanken um die Verteilung des Paketes auf den Servern zu machen.

     

     

    Viele Grüße

     

    Frank

  2. Hallo junger Padawan,

     

    das was Du fuer 2003 gefunden hast, kannst Du nahtlos auch auf 2008 anwenden. Alllerdıngs solltest Du den Kunden vorher dıe Vorteıle von Wındows DNS darlegen. Gerade ım Zusammenspıel mıt AD ıntegrierten Zonen hast Du mehrere Vorteile dıe eıgentlıch gegen BIND sprechen. Vielleicht beschreıbst Du nochmal dıe Umgebung des Kunden besser, damıt ıch verstehen kann warum der Kunde unbedıngt beı BIND bleıben wıll.

     

    Grüsse aus dem Urlaub,

     

    Frank

  3. Moin,

     

    ich glaube, Yusuf steht gerade auf dem Schlauch;-).

    So wie ich den Post verstehe, fragt der OP danach, ob die Trusts auch in die neue Gesamtstruktur migriert werden können. Das geht leider nicht. Wenn die "alte" Windows 2000 Domäne platt ist, dann sind auch die Vertrauensstellungen platt. Diese müssen also mit den anderen Domäne neu eingerichtet werden können.

     

    Viele Grüße

     

    Frank Röder

  4. Hallo,

     

    man könnte das doch so machen:

     

    1.) Erstellen einer CSV Datei in der mehrere Spalten mit den Attributen existieren. In der ersten Spalte ist der alte samAccountName enthalten.

     

    2.) Ein Script sucht dann in der neuen Domäne den alten samAccountname und beginnt danach dem User die neuen Attribute unterzuschieben. Da lässt sich dann auch gleich ein neuer samAccountname erstellen.

     

    Fertige Skripte mit Beispielen findest Du im Technet Skriptcenter.

    BTW: Ich kann Dir natürlich nicht das Erstellen des Skriptes abnehmen. Ohne Erfahrung kann man dort auch viel falsch machen.

     

    Viele Grüße

     

    Frank

  5. Hallo,

     

    Du hast einen gedanklichen Fehler. Warum migrierst Du denn nicht alle User mit ADMT und machst danach ein move-mailbox. Danach kannst Du Dir ein Skript bauen, was die migrierten Nutzer durchläuft und um die entsprechenden Attribute ergänzt.

     

    Ein neues Anlegen der Nutzer wird Dich ins Unglück führen!

     

    Es gibt noch eine Möglichkeit. Man könnte dem neuen Nutzer den alten exchangelegacydn als zusätzliche x500 Adresse hinzufügen. Das ist zwar technisch machbar aber die ungünstigste Lösung.

     

    Grüße

     

    Frank

  6. Der Name des Nutzers ist doch Schall und Rauch. Bei der Migration ist der ExchangeLegacyDN wichtig. Der wird doch durch das ADMT mit migriert. Dann gibt es durch move-mailbox einen Match zwischen alten und neuem Objekt. Du sollltest auch noch etwas Gedanken daran verschwenden wie die Outlookprofile der User nach der Migration angepasst werden.

     

    Grüße

     

    Frank

  7. Hallo,

     

    ich sehe für Euch nur zwei Möglichkeiten:

     

    1.) Ihr setzt euch mit ADMT und move-mailbox (Crossorg) auseinander.

     

    2.) Ihr holt euch einen externen Consultant für zwei Tage in die Firma der mit euch einen Migrationsworkshop durchführt. Dadurch kann der euch die Fragen beantworten und die ersten Schritte durchziehen bzw. darlegen. So eine Migration ist mit Erfahrung so in drei bis vier Tagen komplett durch.

     

    <WERBUNG>

    Ich kenne da einen ziemlich guten;-)

    </WERBUNG>

     

    Wenn ihr den Weg geht, den ihr gehen wollt dann wird das zu viel Tränen und Ärger bei den Usern führen. Die werden euch verfluchen (Stichwort: exchangelegacydn, neue SIDs etc.)

     

     

    Viele Grüße

     

    Frank

  8. Hallo,

     

    entziehe einfach den Usern die Admin Rechte! Die WLAN Verbindung solltest Du damit erschlagen können, das Du die User in die Gruppe der Netzwerkoperatoren aufnimmst. Dann können die an den Netzwerkverbindungen spielen. Dem Virenscanner sind die Benutzerrechte egal, da er unter local System läuft und seine Updates selber zieht und auch installiert. Voraussetzung dafür ist natürlich ein korrekt konfigurierter Scanner.

     

    Viele Grüße

     

    Frank

  9. Hallo,

     

    prüfe mal unter folgendem Regkey:

     

    HKLM\System\CurrentControlSet\Control\SecurePipeServers\winreg\AllowedPaths

     

     

    Da sollte es einen REG_Multi_SZ geben. Dort sollte Folgendes mit enthalten sein: "System\CCS\Services\Wins"

     

    Zusätzlich sollte das Konto "Lokaler Dienst" Leseberechtigung auf den Schlüssel "HKLM\System\CurrentControlSet\Control\SecurePipeServers\winreg\AllowedPaths" haben. Die NTFS Berechtigungen würde ich auchmal prüfen auf dem Verzeichnis WINS unterhalb von system32.

     

     

    Grüße

     

    Frank

×
×
  • Neu erstellen...