BlackArchon

Ich habe hier einen Windows Server 2003 SBS "geerbt", dazu ca. 30 Clients, Tendenz steigend. Bei den Clients sind XP 32 Bit sowie Win7 32 und 64 Bit vorhanden. Es existiert ein AD, die Benutzerprofile sind servergespeichert und es gibt eine Ordnerumleitung für "Eigene Dateien" (offline verfügbar). Leider klappt das alles nicht so recht, vor allem mit den Offlinedateien gibt es regelmäßig Schwierigkeiten. Manche Leute hier sind gleichzeitig auf zwei Rechnern angemeldet (XP und Win7). Man sieht dann z.B. beim Ordner "Eigene Dateien" noch Ordner, die sich nicht löschen lassen - man kann sie problemlos mit Entf löschen, sie sind dann aber sofort wieder da. Direkt auf dem SBS gibt es jedoch diesen Ordner gar nicht mehr. Dann klappt bei einigen Leuten die Synchronisierung der Offlinedateien nur teilweise - aus nicht sofort ersichtlichen Gründen können einige Dateien nicht synchronisiert werden (mit Meldungen wie "Der angegebene Netzwerkname ist nicht mehr verfügbar."). Dann dauern die Anmeldevorgänge bei einigen Leuten sehr lange - obwohl die Offlinedateien nur beim Abmelden synchronisiert werden. Jedenfalls ist hier einiges im Argen und ich versuche gerade, etwas Ordnung reinzubringen. So bin ich auf einige prinzipielle Fragen gestoßen, die ich gern hier diskutieren möchte: - Hat es eigentlich überhaupt Sinn zu versuchen, XP- und Win7 32-/64-Bit-Benutzerprofile mit Server 2003 SBS unter einen Hut zu bringen? - Wäre ein Umstieg auf SBS 2011 nicht vielleicht sinnvoller? - Ich habe noch nicht richtig verstanden, wie die Offlinedateiensynchronisierung bei den verwendeten Windows-Versionen im Detail funktioniert. Leider habe ich dazu auch noch kein Dokument gefunden, wo das genau beschrieben steht (z.B. nach welchem Algorithmus Windows da arbeitet). Sicher kann mir doch hier jemand einen Hinweis geben. Ich bin für jeden Beitrag dankbar.

Die Nutzerprofile liegen auf einem Windows 2003 Server SBS, sind also servergespeichert. Wie würde das konkret ablaufen, wenn die *.ost-Dateien mit ins Profil reinkommen sollen? Aktuell ist es ja so, dass keine *.ost-Dateien auf dem Server in den Profilen liegen. Den Zugriff per OWA würde ich eher als letzte Möglichkeit sehen wollen.

Hier stehen Rechner mit Windows XP und 7 sowie den MS-Office-Versionen 2003, 2007 und 2010 (jeweils voll gepatcht). Letzten Freitag hatte ein Nutzer folgendes Problem: Normalerweise nutzt er einen XP/Office 2007-Rechner, um per Outlook auf sein Exchange-Postfach zuzugreifen. Nun wollte er aber auch mal mit einem anderen Rechner (XP/Office 2010) auf seine E-Mails zugreifen. Das klappte auch soweit problemlos. Nachdem er aber dann wieder mit seinem XP/Office 2007-Rechner Outlook starten wollte, bekam er diverse Fehlermeldungen ('Sie besitzen nicht die aktuelle Version des Microsoft Exchange-Messagingdienstes. Erstellen Sie ein neues Profil.' und 'Das E-Mail-Profil "Outlook" wurde mit einer neueren Outlook-Version erstellt und kann Informationen enthalten, die mit der aktuellen Outlook-Version nicht kompatibel sind. Falls Probleme mit diesem Profil auftreten, können Sie ein neues Profil erstellen...' und zu Guter letzt 'Microsoft Office Outlook kann nicht gestartet werden. Das Outlook-Fenster kann nicht geöffnet werden. Diese Ordnergruppe kann nicht geöffnet werden. Der Informationsspeicher steht zur Zeit nicht zur Verfügung.'). Temporär konnte ich das Problem lösen, indem ich in der Systemsteuerung, E-Mail das Profil "Outlook" gelöscht und neu erstellt habe. Sobald er aber wieder einmal Outlook 2010 auf dem anderen Rechner gestartet hatte, begann das Problem von Neuem. Gibt es da einen Workaround für das Problem?

"Group Policy Preferences" - unter Download: Group Policy Preferences Overview - Microsoft Download Center - Download Details steht, dass das ein neues Feature von Windows Server 2008 wäre. Ich habe aber hier einen Windows Server 2003 SBS-Rechner.

Hm, wenn ich das jetzt recht lese, dann wird das doch noch gar nicht unter Windows 2003 Server unterstützt?

Ok, es liegt wirklich am Windows Server-Rechner. Kopiere ich die großen Dateien auf einen anderen Rechner, gibt es keine Probleme. Gibt es denn keine weiteren Stellschrauben zum probieren?

Ich habe jetzt auf beiden Systemen diesen Registry-Key gesetzt, jedoch keine Besserung. Diese Meldung kommt immer noch. Die Auslagerungsdatei ist auch auf systemverwaltet. Was könnte ich noch tun?

Hm, hast du da zufällig einen heißen Tipp für ein kleines Tutorial zur Erstellung eines solchen Dienstes?

Vorhanden ist ein Windows Server 2003 SBS R2 mitsamt Exchange 2003. Ein Nutzer hier bekommt einen zweiten Benutzer-Account im AD. Sein erster Account (nutzer1) hat natürlich schon ein Exchange-Postfach und kann damit auch problemlos E-Mail intern und extern senden (nutzer1@xyz.de) und empfangen. Nun soll dieser Nutzer einen zweiten Account im AD bekommen. Dieser zweite Account (nutzer1_2) soll dann natürlich auf die gleichen E-Mails Zugriff haben und auch unter der gleichen E-Mail-Adresse Mails versenden (also von nutzer1@xyz.de, nicht von nutzer1_2@xyz.de) können. Mit Exchange hatte ich leider bisher noch nicht so viel zu tun, deshalb weiß ich nicht so recht, was da der eleganteste Weg ist (Ein zweites Exchange-Postfach anlegen? Oder gibt es einen Weg, damit nutzer1_2 das selbe Exchange-Postfach wie nutzer1 benutzen kann?).

Ich habe mir jetzt dieses Kapitel zu den Anmeldeskripts des Buches "Integrationshandbuch Microsoft-Netzwerk" durchgelesen. Muss man also wirklich über so ein Tool wie runas oder psexec (aus der Sysinternals Suite) gehen, wenn man eine DLL per Anmeldeskript registrieren möchte? Oder gibt es noch eine andere Möglichkeit?

Hm, also ich habe auch gerade neue Erkenntnisse gewonnen. Ich habe erstmal mit dem Anmeldeskript für einen Nutzer im AD (unter Eigenschaften, Profil) weiter getestet. Aktuell sieht das so aus: @echo on echo %time% >> c:\test1\testfile.log copy /Y "\\server\projecte\10053_Makro\AddIns\Bibliothek\dsofile.dll" C:\test1\ if %ERRORLEVEL% NEQ 0 GOTO ERROR1 regsvr32 /s c:\test1\dsofile.dll if %ERRORLEVEL% NEQ 0 GOTO ERROR2 GOTO END :ERROR1 echo ### Fehler (1) beim Kopieren der DLL! ### pause GOTO END :ERROR2 echo ### Fehler (2) beim Registrieren der DLL! ### pause :END Dies führt zum errorlevel 5 bei der Ausführung von regsvr32, was auf nicht ausreichende Rechte hinweist. Ich kann jetzt nochmal probieren, die DLL direkt in %windir%\system32 zu kopieren und dort zu registrieren. Mal schauen, aber ich denke nicht, dass sich da was ändert. Ok, erwartungsgemäß konnte ich da nicht mal die DLL kopieren, wegen 'Zugriff verweigert'. Hm, offenbar bin ich die ganze Zeit fälschlicherweise davon ausgegangen, dass das Anmeldeskript mit Adminrechten läuft und nicht mit Benutzerrechten.

Ausgangssituation: Ein Windows 2003 Server R2 SBS mit einem AD, dazu ein paar Windows XP und Win7-Clients. Die Benutzer melden sich an ihren Clients an die Domäne an. Ich möchte sicherstellen, dass bei jedem Rechnerstart der Clients eine bestimmte DLL registriert ist, die ich über das Netzwerk (auf einer Freigabe des Servers) bereitstelle. Da normale Benutzer auch nur Benutzerrechte (und keine Adminrechte) haben, kann ich also nicht einfach per Anmeldeskript (unter AD-Benutzer und -Computer, zur OU der Nutzer gehen, Eigenschaften, Profil) mir diese DLL vom Netz kopieren und einen regsvr32-Aufruf ausführen. Also war mein nächster Gedanke, dies per Gruppenrichtlinie zu erledigen. Dazu habe ich beim Gruppenrichtlinienobjekteditor ein neues Objekt erstellt und bei Computerkonfiguration, Windows-Einstellungen, Skripts (Start/Herunterfahren), Starten ein Skript hinterlegt, welches sich die DLL in %USERPROFILE% kopiert und dann regsvr32 ausführt. Leider scheint dieses Skript völlig ignoriert zu werden. Zum Test habe ich in diesem Skript die aktuelle Uhrzeit in eine Datei schreiben lassen - diese Datei wird jedoch nie angelegt. Daraus schließe ich, dass eben das Skript gar nicht ausgeführt wird. Was könnte ich noch übersehen haben? Ich bin für jeden Vorschlag dankbar.

Probier ich gleich mal aus, danke. :)

Unser Windows Server 2003 SBS SP2 ist recht stark ausgelastet (nur vom Arbeitsspeicher her, aber mehr als 4 GB RAM gehen eben leider nicht). Wenn ich nun eine große Datei von 30 GB auf den Server kopieren möchte, bekomme ich kurz vor Schluss die Meldung "Nicht genügend Serverspeicher verfügbar", die natürlich nichts mit dem verfügbaren Plattenplatz zu tun hat (da ist genügend vorhanden). Falls ich es anders herum probiere, und vom Server aus diese große Datei kopieren möchte, kommt recht schnell eine ähnliche Meldung, dass nicht genügend Ressourcen frei wären. Was kann man da tun, damit ich trotzdem solche großen Dateien kopieren kann?

@XP-Fan: Das wäre natürlich eine Maßnahme, da vielleicht mal über zwei Wochen weg ein Tagebuch zu führen, wo ich alle administrativen Tätigkeiten genau zeitlich erfasse. Sowas wäre zumindest als Anfang sicher nicht verkehrt... Danke, ich denke, so werde ich mal beginnen. Server abschalten will ich lieber nicht. ;)

Ich brauche mal bitte einen nicht hundertprozentig technischen Ratschlag: Wie kann ich meinem Chef deutlich machen, dass die Firmen-IT nichts ist, was sich mal eben so, quasi nebenbei, erledigt? Hintergrund ist, dass ich (seit wenigen Monaten angestellt als Systemadministrator) immer mehr nicht direkt IT-bezogene Aufgaben bekomme und ich deshalb für die Administration der Firmen-IT immer weniger Zeit habe. Die Einstellung meines Chefs ist auch prinzipiell so, dass die IT nichts ist, wo man sonderlich viel Zeit und Arbeit reinstecken muss. Viele Jahre klappte es ja hier auch ohne einen IT-Menschen - das stimmt prinzipiell auch, aber dadurch ist hier ein riesiges Chaos entstanden und gerade unser Server mitsamt allen Client-Diensten läuft zwar noch irgendwie, aber schön ist das alles nicht. Wenn das so weiter geht, wird es in nicht naher Zukunft hier sicher ein größeres Problem geben. Das möchte ich gern verhindern. Aber wie kann ich es schaffen, die Wichtigkeit der IT meinem Chef klar zu machen? Mir fehlen da wirklich ein paar Ideen.

Hier ist ein Windows Server 2003 R2 SBS im Einsatz, der einige Verzeichnisse per Windows-Freigabe anbietet. Nun kommt es ab und zu vor, dass ein Benutzer auf seinem Client-PC (Windows XP und 7) auf diesen verbundenen Netzlaufwerken aus Versehen eine Datei löscht. Wie bei Windows üblich (worüber ich mich schon ewig ärgere) wird ja der lokale Papierkorb bei solchen Löschvorgängen übergangen. Immer dann eine gelöschte Datei aus dem Backup vom Bandlaufwerk wiederherstellen ist ziemlich mühselig. Was kann ich also tun, um das zu vereinfachen? Die beste Lösung wäre wirklich, wenn man den Clients per Richtlinie verordnen könnte, den Papierkorb bei solchen Löschvorgängen zu verwenden. Denn dann könnte derjenige eine versehentlich gelöschte Datei selbst wiederherstellen. Leider habe ich so eine Möglichkeit noch nicht entdeckt. Theoretisch sollten ja die Schattenkopien das bewerkstelligen können, was ich mir wünsche. Sie sind auch auf dem Laufwerk mit den Freigaben aktiviert. Wenn ich jedoch einfach von einem Client-PC eine Datei auf einem Netzlaufwerk lösche und dann zu "Vorgängerversion wiederherstellen" gehe, sagt mir Windows entweder, dass es keine vorherigen Versionen gibt - oder es zeigt mir viele Versionen (lustigerweise alle mit der selben Zeit, siehe Screenshot) an. Ich kann dann zwar diesen Ordner öffnen, jedoch fehlt dann die soeben gelöschte Datei, ich kann sie also so nicht wiederherstellen. Was könnte ich denn da noch probieren?

Danke sehr, da ist es drin! :) Ok, dann werde ich mal nachforschen, warum viele Rechner hier diese Einstellung einfach ignorieren...

Folgende Situation: Hier steht ein Windows 2K3R2 SBS-Server mit einem AD. Dann haben wir hier ca. zwanzig Clients mit Windows XP oder 7 drauf. Einer dieser Rechner mit XP Professional hat noch eine viele Jahre alte Installation drauf, wo ich noch nicht in der Firma war. Bei diesem einen Benutzer ist sein 'Eigene Dateien'-Ordner zu einer Netzwerkfreigabe des Servers umgebogen ('Eigene Dateien' zeigt jetzt also auf \\server\freigabe). Ich möchte das ändern, da er der einzige ist, bei dem das noch so ist. Leider finde ich nicht die Einstellung, wo das zu ändern ist. Ein Rechtsklick auf den Ordner zeigt mir den Zielort \\server\freigabe nur ausgegraut an. In der Registry unter HKCU\Software\Microsoft\Windows\Current Version\Explorer\UserShellFolders\Personal steht auch \\server\freigabe drin und ich kann das auch ändern, aber beim nächsten Windows-Start ist wieder alles beim Alten. Also dachte ich an ein Login-Script, aber ein Blick in die Active Directory-Benutzer und dann zu 'Profil' des Nutzers zeigt mir keine Abweichungen zu all den anderen Nutzern an, das wird es also eher auch nicht sein. Dann kam mir die Idee, vielleicht ist es ja eine lokale Richtlinie. Aber gpedit.msc zeigt mir auf dem Rechner des Nutzers auch nichts Verdächtiges an. Der Autostart-Ordner des Nutzers hat auch nichts drin. Deshalb meine Frage: Wo könnte man so ein Verhalten noch einstellen? Wo könnte ich noch gucken? Was habe ich übersehen? :confused:

Keine Idee? :(

Ich muss hier einfach wieder mal meinen Server vollkommen neu installieren. Doch meine Einstellungen möchte ich natürlich behalten. Die Einstellungen der Firewall von Windows XP SP2 habe ich schon gefunden (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile), jedoch nicht die Einstellungen der Internetverbindungsfreigabe (ICS). Früher waren die mal in der sharedaccess.ini zu finden, doch seit SP2 wohl nicht mehr. Ich habe schon versucht, in der Registry den Eintrag zu finden (habe nach dem Name der Dienstbeschreibung [also wie die Regel heißt, die einen bestimmten Port weiterleitet] in der Registry gesucht, so bin ich auch zu dem Speicherort der Firewall-Einstellungen gekommen), doch nichts gefunden. Wo finde ich diese Einstellungen also?

Problem gelöst: An meinem PC (PC1) lag es nicht. Habe es heute mal mit einem User getestet, der sich direkt (ohne Router) einwählt. Geht problemlos. Also wird sich da doch wohl der Elsa-Router quer gestellt haben. Ich werd mir mal genau die Anleitung für den durchlesen. Danke erstmal! :)

Mehrfach gecheckt, IP-Adressen stimmen. Ping, http-Zugriff auf die Rechner untereinander klappt wunderbar. Ich werde wohl mal einen anderen User (ohne Router ;)) dazu überreden müssen, mit mir zu testen.

Router: PC2 geht über einen Router. Habe das reineditiert. Details: siehe Anhang. Verbindng zu anderem VPN-Server habe ich noch nicht probiert.

Folgende Situation: PC1: Windows 2000 Pro mit SP3. Ist per RASPPPoE-Treiber und T-DSL ins Internet eingewählt. Dort wollte ich eine eingehende VPN-Verbindung zulassen. Bin also auf Systemsteuerung, Netzwerk- und DFÜ-Verbindungen, Neue Verbindung erstellen, Eingehende Verbindungen akzeptieren. Bei Verbindungsgeräte wird nur die Netzwerkkarte angezeigt, die mit dem DSL-Modem verbunden ist, habe das Häkchen davor gesetzt, es aber auch einmal ohne Häkchen probiert. Dann Virtuelle private Verbindungen zulassen. Und einen Benutzer zugewiesen. Bei Netzwerkomponenten ist alles aktiviert, habe nichts geändert. Richtig so? PC2: Windows XP Pro mit SP1. Geht über einen Elsa Lancom-Router online, der auch per T-DSL einwählt. Dort bin ich auf Systemsteuerung, Netzwerkverbindungen, Neue Verbindung erstellen, Verbindung mit dem Netzwerk am Arbeitsplatz herstellen, VPN-Verbindung, keine Anfangsverbindung automatisch wählen (weil die sowieso quasi immer besteht), dann die aktuelle IP-Adresse von PC1 eingetragen. Und Benutzername und Passwort eingegeben, auch mehrmals überprüft. Wenn ich jetzt die VPN-Verbindung von PC2 zu PC1 aufbauen wil, bekommt PC2 folgende Fehlermeldung. Was tun?