nails80

Wir werden in den nächsten Monaten den alten Mac-Server eh raus schmeißen, also kann ich mit der Lösung bis dahin leben. Der alte MAc-Server wird gegen einen Windows-Server ersetzt, wo ich dann definitiv keine Probleme bezüglich robocopy haben werde. Danke nochmal für den Tipp!

Es funktioniert tatsächlich mit der alten Robocopy-Version... was für ein schei... Danke für den Tipp!!! Wäre natürlich jetzt interessant zu wissen, warum das mit der neuen Version von robocopy nicht funktioniert und bei der alten schon, aber ich bin ja erstmal froh, dass es überhaupt funktioniert. Danke nochmal!

@zahni Ja es ist die 2008R2 robocopy-Version. @Dukel Kann ich prinzipiell machen, aber der Server fragt normalerweise nach einem Benutzernamen und Password. Da ich diese nicht als Klartext in der Batch-Datei hinterlegen möchte, gehe ich den Weg über das Netzlaufwerk. Machte unter 2003 auch keine Probleme. Wie schon gesagt mit dem Windows-Explorer habe ich kein Problem die Datien zu kopieren.

Hallo an alle, wir haben unseren alten Win2003 File-Server gegen einen 2008R2 ausgetauscht. Soweit funtkioniert auch alles, aber ich habe ein Problem mit robocopy. Wir lassen mit einer Batch-Datei einen robocopy-Befehl ausführen, der neue PDF-Dateien von einem MAC-Server auf den neuen 2008er-Server kopieren soll. Die Batch-Datei sieht wie folgt aus: robocopy "X:" "D:\Pdf\" *.pdf /w:1 /r:1 /NS /NC Folgender Fehler wird nur bei neuen/geänderten PDF-Dateien angezeigt: "2011/12/07 16:02:35 FEHLER 2 (0x00000002) Zugriff auf Zielverzeichnis X:\ Das System kann die angegebene Datei nicht finden." X steht für das Netzlaufwerk, welches mit "\\192.168.1.45\pdf" und den entsprechenden Benutzerinformationen des MAC-Servers verbunden ist. Die IP-Adresse des Mac-Servers habe ich unter den Internetoptionen --> Lokales Intranet --> Sites hinzugefügt. Im Windows-Explorer kommt dadurch auch keine Sicherheitwarnung, wenn ich Dateien von dem Mac-Server auf den Windows-Server kopiere. Unter 2003 macht die Batch keine Probleme, nur unter 2008... Was hat sich den bei 2008 geändert, dass diese Batch nicht mehr funktioniert? Hat irgendjemand eine Idee oder Ansatz, wo ich weiter suchen könnte? Mir sind die Ideen momentan leider ausgegangen... Bin für jeden Tipp dankbar face-smile Beste Grüße Simon

erst mal Danke für die Antwort. Prinzipiell hast du Recht... das wäre am einfachsten, aber der Anwender soll einfach das E-Mail Konto zum Versandt auswählen können und automtisch die entsprechende Signatur erscheinen. Das kann ich nur mit einem IMAP Konto realisieren... leider. Exchange-Postfach über IMAP ist schon die einzige Lösung für unseren Zweck. Zur Not muss ich hat ein 2007er Outlook an dem PC installieren. Damit funktioniert es auf jeden Fall. Ich würde eigentlich nur gerne wissen, warum dass nicht mit Outlook 2003 funktioniert.

Hallo an alle, Umgebung: Exchange 2003 Server 2x Exchange Postfach für einen Benutzer (Postfach A + Postfach B) Outlook 2003 Problem: - Ein Active Directory Benutzer benötigt benötigt zwei getrennte Postfächer. - Es sind zwei Active Directory Benutzer mit Postfächern eingerichtet. Das Recht "Senden als" wurde im AD auch gesetzt. - Sein Hauptpostfach (Postfach A) wird in Outlook einfach als normales Exchange-Postfach eingerichtet. - Sein zweites Postfach (Postfach B) wird als IMAP-Postfach eingerichtet. (Anmelden an Postausgangsserver ist auch aktiviert) - Er kann auch darauf zugreifen und ankommende E-Mails lesen. - Er kann auch intern E-Mails mit Postfach B versenden, aber nicht nach extern. Dann erhält er folgende Fehlermeldung: "550 5.7.1 Unable to relay for xxxx@xxxxxxx.xxx" Wenn ich das mit einem Outlook 2007 ausprobiere, funktioniert der Mail-Versand über das IMAP-Konto ohne probleme. Nur mit Outlook 2003 eben nicht. Die Outlook einstellungen von 2003 und 2007 habe ich mehrfach verglichen und auch an insgesamt vier verschiedenen PCs getestet. Ich kann nicht feststellen warum das mit Outlook 2003 nicht funktioniert. Hat jemand zufälligerweise den ultimativen Tipp für mich? Grüße

Bei 2003 war es ja immer so, dass nur die Administratoren oder Benutzer mit Admin-Rechten den Servermanager zu Gesicht bekommen. 2008 habe ich aber selbst noch nicht aufgesetzt.

Hallo an alle, ich habe einen Terminalserver (TS) mit mehreren Sprachen neu aufgebaut. Funktioniert auch soweit ganz gut. Die Anzeigesprachen im Startmenü und Office werden auch ordnungsgemäß angezeigt, doch die Eingabesprache steht immer auf Englisch. Es wird nur die Anzeigesprache geändert, aber nicht die Eingabesprache. Dadurch stimmt das Tastatur-Layout für die deutscher und französischen Mitarbeiter nicht, und man muss die immer manuell umstellen. Gibt es eine Möglichkeit die Eingabesprache auch über eine Gruppenrichtlinie zuzuordnen, sodass man nicht mehr manuell umstellen? Folgende Konfiguration: Win2003-Server R2 SP2 Win2003 Multi-User-Interface Office 2007 Multi-Language-Pack Im Active Directory sind für die verschiedenen Sprachen Organisationseinheiten (OU) angelegt, wo entsprechende Gruppenrichtlinien die Sprache bestimmen (Deutsch / Englisch / Französisch). Die User werden in die entsprechenden OUs geschoben und somit übernimmt der TS die Anzeigesprachen für das Startmenü und Office. Schönen Gruß Simon

Hallo Nils, funktioniert wie es sein soll. Wünsche ein schönes Wochenende und vielen Dank !!!! Grüße, Simon

Hallo Nils, vielen dank für deine Antwort. Das mit dem Builtin habe ich verstanden, aber folgendes verstehe ich nicht so ganz: "Du suchst die gleichnamige Gruppe auf dem Terminalserver. Ändere also den Suchbereich in dem Auswahlfenster für die Gruppe." Wenn die OU "Builtin" nur für DCs ist, dann kann ich die "Remote Desktop Users" nicht für den Terminalserver verweden, weil er ja kein DC ist. Also muss ich doch im Active Driectory einen neue Gruppe anlegen und diese dann für die RDP-Verbindungsberechtigung verwenden, oder? schönen Gruß, Simon

Hallo zusammen, folgendes Konfiguration ist bei uns vorhanden: - Win2003 Server als DC - Active Directory - Win2003 Server als Terminalserver (Domänenmitglied -- kein DC) Problem: Im Active Directory gibt es ja die OU "Builtin", wo auch die Sicherheitsgruppe "Remote Desktop Users" existiert. Jetzt möchte ich auf dem Terminalserver (Domänenmitglied) die RDP-Verbindung unter "Terminaldienste Konfiguration" anpassen. Dort fehlt in der Karteikarte "Sicherheit" die Gruppe "Remote Desktop Users". Diese Gruppe kann ich aber nicht hinzufügen, da diese einfach nicht zu finden ist. Mir werden alle anderen Benutzer vom ActiveDirectory angezeigt, aber alle Gruppen unter "Builtin" werden mir auf dem Terminalserver einfach nicht angezeigt. Somit kann ich den Terminalserver nicht dazu bringen, dass sich die "Remote Desktop User" auf dem Terminalserver anmelden dürfen. Was habe ich vergessen, oder wo ist mein Fehler??? Hat irgendjemand eine Idee? schönen Gruß Simon

Ausserdem funktioniert ja der Treiber mit Adminstrator-Rechten, nur halt nicht als normaler TS-User mit Benutzer-Rechten. Also ein generelles Treiber-Problem kann es nicht sein. Es kann eher so sein, dass der Treiber auf dem TS halt Probleme mit normalen Benutzer-Rechten in einer TS-Session hat. Wenn noch jemand eine Idee hätte, wäre das natürlich toll.... Gruß Simon

Ich glaube nicht dass der Treiber offiziell freigegeben ist. Aber es hatte mal mit dem Treiber funktioniert.... Es kann auch sein, dass irgendein MS-Update den Druckertreiber stört. Aber es ist nur eine Vermutung.

Hallo zusammen, habe ein seltsames Problem und stehe leider ein wenig auf dem Schlauch. Folgendes Szenario: W2k3 Terminalserver (TS) XP-Client HP Officejet USB Drucker Ich habe den Registry-Wert "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns\RDPDRFilterQueueType = ffffffff" (DWORD) gesetzt, damit alle lokalen Drucker auch an dem TS angezeigt werden + die Treiber sind auch auf dem TS installiert. (beide verfügbaren Treiber von HP sind schon getestet) Der HP Drucker wird auch in der TS-Sitzung angezeigt und man kann ihn auch ganz normal anwählen, aber als normaler TS-Benutzer kommt kein Ausdruck aus dem Drucker. ABER wenn ich mich als Administrator an dem TS anmelde (von dem betroffenen Client natürlich) kann ich auf diesem Drucker ganz normal ausdrucken. Ohne Probleme. Im Ereignis-Protokoll bin ich auch fündig geworden, wenn ich als normaler TS-Benutzer versuche zu drucken (ohne Admin-Rechte): Ereignistyp: Fehler Ereignisquelle: Print Ereigniskategorie: Keine Ereigniskennung: 6161 Datum: 26.08.2008 Zeit: 11:47:02 Benutzer: Domäne\XXXX Computer: XXXXXXXXX-TS1 Beschreibung: Das Dokument Testseite, im Besitz von XXXX, konnte nicht auf dem Drucker hp officejet d series (von XXXXX-TEST-PC) in Sitzung 1 gedruckt werden. Datentyp: NT EMF 1.008. Größe der Warteschlangendatei in Bytes: 196608. Anzahl der gedruckten Bytes: 0. Gesamtanzahl der Seiten des Dokuments: 1. Anzahl der gedruckten Seiten: 0. Clientcomputer: \\XXXXXXXXX-TS1. Vom Druckprozessor zurückgelieferter Win32-Fehlercode: 5. Zugriff verweigert Den Spooler-Ordner auf eine andere Partition ändern, volle Rechte für alle setzen, und Spooler neustarten bringt auch nichts. Wenn ich einen Brother-Drucker über USB anschliesse und mit der automatischen Druckerweiterleitung verwende, funktioniert alles sofort. Auch als normaler TS-Benutzer. Das scheint ein Rechte-Problem oder ein Treiber-Problem zu sein, aber was kann ich noch tun??? Gibt es noch Möglichkeiten? Hat jemand das schon einmal gehabt? Bin für jeden Hinweis zu haben.... Verzweifelte Grüße Simon