Jump to content

fritzo

Abgemeldet
  • Gesamte Inhalte

    259
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von fritzo

  1. 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:

     

    Windows 2003 time zone redirection

     

    Windows 2003 servers allow client computers to redirect their time zone settings to the terminal server so that users see the correct time for their time zone in their desktop/application sessions. Terminal Services uses the server base time on the terminal server and the client time zone information to calculate the time in the session. This feature may be useful if you have clients in different time zones.

     

    By default, this feature is disabled. To enable the feature:

     

    1. Either:

    * start the Microsoft Group Policy Management Console; or

    * start an empty Microsoft Management Console (by running mmc.exe from the Start, Run menu) and add the Group Policy Object Editor snap-in.

    2. Select the group policy object you want to edit.

    3. Click Computer configuration, Administrative Templates, Windows Components, Terminal Services, Client Server Data Redirection.

    4. Open Allow Time Zone Redirection.

    5. Click Enabled.

    6. Click OK.

     

    Grüße,

    Fritz

  2. 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

  3. 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:

    This problem is documented by Microsoft in their knowledgebase article KB322303 (the article refers to serial port printers, but the same issue applies to the somewhat atypical configuration of RedMon). The solution, according to Microsoft and verified by some quick tests in my den, is to apply SP1 for Windows XP. This replaces the file localspl.dll with a version that resolves the problem. Alternatively, it may be possible to simply replace this one file with the SP1 version to achieve the same results - if you can confirm (or deny) that this works, let me know at heretrythis at comcast dot net.

     

    --> 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

×
×
  • Neu erstellen...