frr

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

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

Hallo, ergänzend zu Nils: How to mark an attribute as confidential in Windows Server 2003 Service Pack 1 Viele Grüße Frank Röder

Hallo, grundsätzlich funktioniert es erstmal. Allerdings musst Du auf den Fileservern noch einen kleinen Kunstgriff erledigen. Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name Den Rechner musst Du übrigens nicht neustarten. Das Starten des Serverdienstes reicht. Viele Grüße Frank

Hallo, das liegt mit so ca. 95%iger Wahrscheinlichkeit an einem faulen Druckertreiber. Was laufen denn da so für Drucker drauf. Viele Grüße Frank

Naja, man könnte ja das Logging des Installers hochdrehen. Dadurch sollte man dann auch ein Logfile haben. Grüße Frank

Korrekt. Genau das ist die Ursache. Ein anderes Problem mit dem WAIK ist mir nicht bekannt. Viele Grüße Frank

Moin Yusuf, ich scheine heute morgen auch noch etwas durch den Wind gewesen zu sein. Ich bin von einer ADMT Migration ausgegangen. Man sollte halt nur antworten, wenn man auch richtig ausgeschlafen ist;-). BTW: Warum du so ausgeschlafen bist, ist mir ein Rätsel. Die Nachtschichten am Kinderbett scheinen sich in Grenzen zu halten. :D Grüße Frank

Hallo, ist das eine Intra Org Migration oder hast Du über zwei Exchange Organisationen migriert. Viele Grüße Frank

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

Hallo Gerry, das ist leider nicht so ohne Weiteres möglich. Das ist mit viel Gefummel verbunden. Du kannst Dir ja mal dieses Whitepaper hier ansehen: http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/PrtTrblSh.docx Grüße Frank

Hallo, wie meine Vor(redner)schreiber das schon vorgeschlagen haben, würde ich das über ein Skript erschlagen: Get-MailboxStatistics | sort-object DatabaseName, TotalItemSize,LastLogonTime | format-table DisplayName, @{expression={$_.TotalItemSize.Value.ToMB()};label="Postfachgroesse in (MB)"}, DatabaseName Grüße Frank

Hallo, kurz und knapp: Du würdest schon bei Step1 auf die Nase fallen. Grundlegendes zur Installation im Modus "/M:RecoverServer" Grüße Frank

Hallo, das bekommst Du gar nicht hin. Da Du ein NAT machst. Deshalb siehst Du nur die IP des Gateways. Du musst ein Routing konfigurieren, damit das funktioniert. Grüße Frank Röder

Hallo, kurz und knapp: Du musst selber über eine RDP Sitzung kommen. Sonst kannst Du das nicht machen. Die Konsole von VMWare ist ja eine Consolensitzung. Deshalb geht das nicht. Viele Grüße Frank

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

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

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

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

Hallo Norbert, das ist schon ein Unterschied ob man das über die Powershell oder über die EMC macht. Die Powershell ist so ca. 5 Min. schneller im Starten;-). Grüße Frank

Hallo, ich würde mir den Stress gar nicht machen. Du könntest ja die Gruppenrichtlinieneinstellungen einsetzen. Da kannst Du auch Netzlaufwerke mappen und kannst für die Zielgruppenaddressierung einzelne IP Bereiche einsetzen. Grüße Frank

Hallo, Du scheinst das Postfach mit dem Exchange Systemmanager verschieben zu wollen. Setze auf dem 2007er das cmdlet move-mailbox ein. Dann passt das. Viele Grüße Frank

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

Hallo, das klingt sehr nach SMB Signing. Gehe bitte nach folgender Anleitung vor, um das SMB Signing richtig zu konfigurieren: SMB Signing - Einstellungen für: Kommunikation digital signieren Danach sollte der Zugriff klappen. Grüße Frank

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