fritzo

Hi, vielleicht hilft das hier evtl.: http://www.microsoft.com/technet/community/scriptcenter/network/scrnet64.mspx Ansonsten scheint es 3rd-party-products dafür zu geben, deswegen ist es wahrscheinlich nicht trivial: http://www.solution-soft.com/timemachine.shtml Sollte Eure Umgebung W2K3-basiert sein, wäre das hier evtl. noch interessant: Grüße, Fritz

Hi, ok.... *grübel* wenn Du jetzt so ganz und gar nicht an die Drucker dran kämst, würde ich Fehler in den Routen vermouten. Aber so kann man das wohl ausschließen. Die Einstellungen in der Citrix Adminkonsole werden es wohl auch nicht sein. Bleibt der ISA. Ihr habt die Außenstellen über den ISA angebunden? Was sagen die Logs des ISA, werden Pakete geblockt? Gibt es evtl. eine Rule, die zwar Connects zulässt, aber dann die Session-Packets blockt (allow udp137/ deny tcp139)? Evtl. lässt der ISA den Connect auf den Drucker zu, blockt aber die eigentliche Session auf den Drucker in das Nachbar-Subnetz.. -wer spoolt die Jobs, Printserver in Eurem oder in dem anderen Subnetz? -werden die Jobs über ICA getunnelt oder direkt vom Printserver an die Printer geschickt? Grüße, Fritz

Hi, nein, Du laberst keinen Müll; nur ich hatte einen kleinen Blackout :rolleyes: Du siehst also die angebundenen lokalen Clientdrucker auf dem MF-Server durchaus, der Fehler kommt erst beim Drucken selbst. Google: --> http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B322303&Product=winxp Hast Du einen der Drucker mal neu angelegt? Kannst Du die Drucker normal über Netz vom MF aus ansprechen (wenn technisch möglich)? Lösch einen der Drucker mal vom MF und vom Client und leg beides neu an. Grüße, Fritz

Hi, wir setzen momentan McAfee ViruScan 7 ein und haben keine Probleme damit, alles läuft sehr sauber im Vergleich zu NetShield 4.5. Grüße, Fritz

Hallo, hat jemand evtl. schon etwas über Fehler bei der Installation der folgenden Hotfixes auf Servern unter NT4/W2K/W2K3 zu berichten? -MS04-012 Kumulatives Update für Microsoft RPC/DCOM (828741) -MS04-013 Kumulatives Sicherheitsupdate für Outlook Express (837009) -MS04-014 Sicherheitsanfälligkeit im Microsoft Jet-Datenbankmodul kann die Ausführung von Programmcode ermöglichen (837001) Dankeschön im voraus. Viele Grüße, Fritz

Hi, ich hab mal versucht, die beiden Lösungen gegenüber zu stellen: 2 PCs Cold Standby -------------------------------- -einfache Administration -unanfällige Technik -geringe Betriebskosten -niedrige Verfügbarkeit -manueller Aufwand im Störungsfall Clusterlösung 2 Nodes ------------------------------------- -hohe Verfügbarkeit -niedriger Aufwand im Störungsfall, wenn nur ein Node betroffen -komplexe Administration -anfälligere Technik -hohe Betriebs/Wartungskosten Wenn Ihr keine hohen SLA habt und eine einfache, kostensparende Lösung wollt, würde ich Cold Standby nehmen. Da Du die Kostenersparnis als Ziel erwähntest, würde ich wiederum zu Cold Standby raten - allerdings ist dabei ja noch zu berücksichtigen, daß die Hardware ja schon da steht. Ansonsten ist ein Cluster im Fehlerfall sehr angenehm, wenn nur ein Node von Fehlern betroffen ist. Ist aber der Cluster selbst oder die DB betroffen, die auf der Clusterressource liegt, sieht es anders aus - dann ist der Aufwand im Fehlerfall wiederum hoch. Hoffe, das hilft ein bißchen. Grüße, Fritz

Hi, hm... ich weiß zwar ad hoc nicht, wo PNA seine Preferences ablegt (wir verwenden CSG/NFuse), aber such doch mal in Deinem Profil (bin nicht sicher, aber es ist evtl. appsrv.ini oder wfclient.ini). Solltest Du fündig werden, kopier die Einstellung nach "All Users". Sollte er es in der Registry ablegen, dann exportier die Einstellung und laß sie durch ein Logonscript für die User anziehen. Ansonsten schau mal bei http://support.citrix.com. Unter Unix kann man es einstellen, unter Windows hab ich noch nichts gefunden. Grüße, Fritz

Hi, wenn es ein Internet-Webserver in der DMZ o.ä. ist, dann würde ich den Patch installieren. Wenn er im Intranet steht, dann nicht unbedingt. Mach vorher ein Backup. Wenn es ein W2K/3-Server sein sollte, erstell ein ASR-Backup mit Diskette. Installier den Patch manuell, beende vorher alle Dienste die Du zur Zeit des Patchens nicht benötigst (Web/Mail/Virenscanner etc), damit möglichst alle Files vor dem Reboot ausgetauscht werden können. Wenn Maschinen nicht wiederhochkommen sollten, benutz die vorher installierte Wiederherstellungskonsole oder erstell Dir eine bootable disk mit "BartsPE". Falls Du RAID1-Arrays haben solltest, kannst Du ja evtl. auch eine Platte vorher als Fallback-Sicherheit ziehen. Viel Erfolg. Generell würde ich abwägen zwischen Nutzen und evtl. entstehenden Kosten durch einen Ausfall. Man muß (imho) nicht unbedingt jeden Server mit jedem Hotfix patchen, wenn er im internen Netz steht. Ansonsten - hoffentlich kommt das nächste SP bald ;O) Grüße, Fritz

Hi, warum willst Du das machen bzw für welche Anwendung soll das sein? Wenn es Outlook sein sollte, so kannst Du die Zeitzonen auch in Outlook selbst umstellen; zumindest unter Office XP geht das. Grüße, Fritz

Hi, normalerweise würde ich Dir dazu raten, eine OU anzulegen, den Terminalserver dort hinein zu packen und dann die Policy nur auf eben dieser OU und nur für Gruppe x zu setzen. a) er kriegt zB auch die Default Domain Controller Policy ab. b) Du mußt ihn sehr, sehr sorgsam abdichten, weil die User ja praktisch lokal auf dem DC arbeiten (one of those things that make you go "hmmm") ;O). Die Gruppe Terminalserverbenutzer bringt Dir dann etwas wenn für Mitglieder dieser Gruppe die Anmeldung am TS erlaubt ist., und zwar auch über das RDP-Protokoll. Ansonsten kannst Du jede beliebige Gruppe dafür nehmen und auf dem Protokoll eintragen ("Terminaldienstekonfiguration/Verbindungen/RDP-Tcp"). Ich trage die lokale Gruppe "Terminalserverbenutzer" als berechtigt ein und füge dieser lokalen Gruppe dann eine globale Gruppe hinzu. In dieser Domänen-Gruppe werden dann die User eingetragen. Für diese Gruppe muß die Policy auf der OU gesetzt sein, in der sich der TS befindet. Zieh die User, sobald Du kannst, auf einen Member Server um, das ist weniger riskant. hope it helps! Grüße, Fritz

Hi, die Idee mit der Suche in der Knowledgebase ist gut: http://support.citrix.com/kb/homepage.jspa Ansonsten - ich kenn Eure Support-Verträge nicht, aber sollten sie es hergeben, kannst Du auch mit Citrix selbst Kontakt aufnehmen. Grüße, Fritz

Hi, wie sind die WINS-Einträge auf den Clients in den Außenstellen? Check bitte mal remote die WINS-Client-Entries und auch die Routen mit route print. Habt Ihr evtl. unterschiedliche Betriebssysteme in Außenstellen und im Zentralstandort? Mach bitte mal ein Traceroute von einem der Clients auf den Printserver. We need more input here in order to help you! Grüße, Fritz

Hi, da anscheinend bis jetzt keine Lösung dafür zustande kam - funk mich mal per ICQ an, dann können wir das mal in Ruhe bequaken. Ich weiß ziemlich genau, wie es ist, wenn man hunderte User und evtl. noch den Chef im Nacken hat, wenn Drucken Citrix mal wieder nicht richtig funktioniert. Grüße, Fritz

Hi, udp oder tcp? Ansonsten sind die Standardports für dns udp53 und für dhcp udp67 (Client-Port 68). Check Deinen Server bitte mal mit Virenscanner, Anti-Trojan-Tools oder portmonitor, das ist schon irgendwie komisch. Kriegst Du ein Banner, wenn Du mit telnet auf den Server connectest (telnet host 110)? Grüße, Fritzo

...es scheint ihr wichtig zu sein *grins Liebe Grüße, Fritz

Hi, öööhm - benenn den Administrator-Account doch einfach um?! Grüße, Fritz

Hi, klar geht das: -auf den Dateien die Usergruppe mit READ berechtigen -auf dem Ordner darüber für die Gruppe folgende -spezielle- Rechte setzen (über Eigenschaften / Sicherheit / Erweitert / Berechtigungen / Bearbeiten): -Übernehmen für: "Nur diesen Ordner" -"Ordner durchsuchen" -"Berechtigungen lesen" Die Rechte entweder per Hand oder mit cacls oder xcacls setzen. Grüße, Fritzo

Hi, vielleicht hilft das hier ein bißchen weiter: http://support.microsoft.com/default.aspx?scid=kb;de;241594&sd=tech http://support.microsoft.com/default.aspx?scid=kb;DE;257288 http://www.google.de/search?q=cache:U_Qw3rqONeYJ:www.datenschutzzentrum.de/download/bu05kap12.pdf+Verzeichnisdienstwiederherstellung&hl=de&ie=UTF-8 Ansonsten: falls Du noch kein Backup hast, mach auf jeden Fall eins! Dann kann man die Daten restoren, falls etwas schief geht. Vielleicht hast Du bei der Wiederherstellung auch nur einige Schritte vergessen, wie zB folgendes: "Führen Sie nach der Wiederherstellung der Daten die autorisierende Wiederherstellung mit "Ntdsutil.exe" durch: 1. Geben Sie an einer Eingabeaufforderung ntdsutil ein, und drücken Sie die [EINGABETASTE]. 2. Geben Sie authoritative restore ein, und drücken Sie die [EINGABETASTE]. 3. Geben Sie restore database ein, und drücken Sie die [EINGABETASTE]. Klicken Sie auf OK und anschließend auf Ja." Grüße, Fritzo

Hi, vielleicht kannst Du die Anleitung hier brauchen: "Konfiguration und Anwendung von Sicherheitsvorlagen mit Windows 2000" http://www.microsoft.com/germany/ms/security/guidance/modules/secmod226.mspx Grüße, Fritz

Hi, ich kenn Deine Konfiguration nicht, vermute aber mal, daß bei Dir User nur von intern connecten. Wenn Deine SW-FW sowas wie stateful inspection hergibt, stell sie am besten so ein, daß sie SMTP nur outbound zulässt (also tcp all ---> tcp25). Ansonsten fällt mir noch ein: POP-before-SMTP, Zertifikate und Filterung auf IP-Ranges. Grüße, Fritz

Hi, daß es erst funktioniert und dann nicht mehr, weist vielleicht auf WINS hin - habt ihr in WINS alle alten Einträge gelöscht und die Caches geleert (nbtstat -RR) bzw. hat der MF die neuen WINS-Server? Grüße, Fritz

Hi, das ist zwar nur für W2K, aber vielleicht hilft es weiter: http://support.microsoft.com/default.aspx?scid=kb;en-us;302443 Grüße, Fritz

Hi, ich denke auch, daß es ein Serienbrief mit Verweis auf eine externe Datenquelle ist. Prüf bitte mal den Link auf die externe Datenquelle und binde sie ggfs. neu an. Ist sie evtl. auf einem nicht erreichbaren Share oder nicht vorhandenem Pfad abgelegt? Sollte das nicht gehen, check mal die ODBC-Einstellungen auf korrekte DSN und Treiber für die Datenbank (wahrscheinlich MSAcess). Grüße, Fritz

Noch ein paar Infos: Gemäß http://www.microsoft.com/windowsserversystem/sus/susfaq.mspx werden folgende Server beim Download angesprochen: http://www.msus.windowsupdate.com http://download.windowsupdate.com http://cdm.microsoft.com Ich habe zwar noch nichts gefunden, würde aber mal vermuten, daß MS den Download der Patches durch ein Zertifikat gesichert hat. Kann das jemand bestätigen? Grüße, Fritz

Hm... die Frage ist gar nicht mal so unberechtigt. In einer Domäne wird der SUS-Server in einer der Policies festgelegt. Bei Standalone-Maschinen ist es wie bereits oben erwähnt msus.windowsupdate.com. Aber mal eine Frage: was geschieht, wenn man im "hosts"-File einen Eintrag für diesen Host setzt und diesen auf eine beliebige IP eines gefakten SUS-Servers verbiegt? Oder wenn man ihn auf dem DNS-Server durch Cache-Poisoning / Spoofing verbiegt? Grüße, Fritzo