Jump to content

Stoertebeker

Members
  • Content Count

    65
  • Joined

  • Last visited

Community Reputation

10 Neutral

About Stoertebeker

  • Rank
    Junior Member
  1. Hi all, keine Ahnung, ob ich in dem Forum richtig bin, aber die anderen Forenthemen passten alle eher nicht, daher versuch ich es mal: Ich betreue nebenberuflich eine kleine Kanzlei mit wenigen Rechnern. Da ich beruflich weggehe haben die sich einen anderen Dienstleister gesucht, der als erstes eine Diagnosesoftware laufen lassen möchte, um den Ist-Zustand aufzunehmen. Dazu braucht er alle admin/root Passwörter. Da das für mich mit der Schlüsselübergabe bei einem Haus vergleichbar ist, bin ich mir nicht sicher, ob ich danach alle Verantwortung für das System ablehnen soll/muss, wie ich
  2. Doch tut es, ich kann ja auch die Ordnerstruktur meiner IMAP-Ordner auf dem Server sehen. Nur nicht darauf zugreifen (s. Ursprungspost). Ob die Konfiguration betroffen ist kann ich noch nicht sagen, da meine Mitarbeiter so weit einfach noch nicht gekommen sind, weil sie an wesentlich grundlegenderen DIngen gescheitert sind.
  3. Ja, das war ja einer der Gründe, weshalb ich auf IMAP wechseln wollte. Denn natürlich wird beim bisherigen Verfahren die pst Datei täglich gesichert, auch wenn der Rechner gar nicht gewechselt wird. Ich habe jetzt mal folgendes probiert: Die .pst Datei des IMAP Kontos (in \Appdata\local) manuell vom ersten auf einen zweiten Rechner kopiert. Jetzt kann ich fröhlich zwischen beiden Rechnern hin- und herwechseln, die IMAP-Ordner synchronisieren sich und ich kann auch Mails verschicken. Werde das jetzt mal mit weiteren Rechnern und Accounts versuchen. Ist zwar lästig, aber wenn es nur einm
  4. ups :schreck: Ich wusste ja, dass pst Dateien nicht auf Netzlaufwerken liegen dürfen, aber dass sie auch nicht im Profil liegen und von dort ins lokale Verzeichnis kopiert werden dürfen, war mir nicht klar - und scheint mir im Widerspruch zu Dukels Aussage zu stehen. Ich mach nochmal nen Versuch, habe vielleicht beim ersten Mal die Situation nicht klar genug beschrieben. Wir verwenden keine Ordnerumleitungen, um das lokale Profil auf den Server umzubiegen, alle von Outlook verwendeten Dateien werden im lokalen Profil genutzt. Dabei geht es um 2 pst-Dateien: 1. Outlook verwendet
  5. Sehe ich das richtig, dass das bedeutet: Outlook und IMAP? Vergiss es! (zumindest wenn die User nicht fest an einem PC arbeiten)?
  6. Hi, ich hoffe, dass ich hier im Forum überhaupt richtig bin, da ich nicht genau weiß, von welchem Ende ich das Problem angehen muss. Im Zweifel schubst mich einfach in die richtige Richtung... ich habe mehrere Win7 Clients an einem 2k3 Server (als AD-Server) laufen, es sind maximal 10 Nutzer, die aber nicht immer am gleichen Client arbeiten. Bis vor kurzem haben wir Outlook verwendet, um per POP die Mails vom Mailserver abzuholen. Die .pst Dateien in Eigene Dokumente\Outlook-Dateien wurden beim Abmelden mit dem Server synchronisiert, so dass sie auf allen Stationen zur Verfügung s
  7. Mittlerweile hat mir jemand gesagt, die Fähigkeit, große Dateien zu teilen / zusammenzusetzen, wäre bei Outlook generell entfernt worden? Stimmt das? Es kann doch nicht sein, dass ich LiveMail nur für diesen Zweck parallel betreiben muss.
  8. Hi all, wir haben einen Netzwerkdrucker, der in der Lage ist, gescannte Dokumente anschließend per Mail als pdf an einen Benutzer zu schicken. Sind diese Mails zu groß (ab mehr als etwa 16 gescannten Seiten) so teilt der Drucker die Mail in mehrere Teile auf. Diese Teile wurden bisher (Windows XP / Outlook 2000) von Outlook direkt (ohne Benutzerzutun) wieder zu einer Mail zusammengesetzt, in der die pdf-Datei als Attachment angehängt war, die einzelnen Teilmails wurden in den Papierkorb verschoben. Nur haben wir auf Win7 / Outlook 2010 aktualisiert und die Mails werden nicht mehr
  9. Sorry, ich wusste nicht, dass das einen Unterschied macht, da der Fehler ja bereits beim Kontaktieren des internen Servers auftritt. Hier die Windowsupdate.log unmittelbar nach dem Workaround (die Aktualisierung der Richtlinie kommt daher, dass ich bis zur Lösung in der Policy den internen Server abgestellt hatte). 8024400e ist leider hartnäckig.
  10. Ich hab nochmal ein windowsupdate.log hier abgelegt. Wie zu sehen: Mit WSUS klappts nicht. Der WSUS hält die Updates aus Platzgründen nicht lokal vor. Die Clients sollen die Updates von MS laden, aber trotzdem den WSUS zum Finden der Updates und Berichten hernehmen.
  11. Den Workaround hatte ich bereits erfolglos ausprobiert, aber danke. Mit den eckigen Klammern wollte ich aussagen, dass ich dort den tatsächlichen Namen durch einen Platzhalter ersetzt habe .-) Proycfg hat zumindest mal das Update über die Microsoft-Webseite ermöglicht (yeah). Lokal über den WSUS geht es immer noch nicht. Je nachdem, ob ich den WSUS versuche direkt (sollte innerhalb des Hausnetzes möglich sein) oder über den Proxy anzusprechen bekomme ich entweder den 8024400e oder einen 80072f78. Im Moment läuft aber erst mal das Update über MS und das werd ich erst mal laufen lassen und e
  12. Ich komme leider immer noch nicht weiter :cry: Hier der Link zur windowsupdate.log: enthalten sind zwei Versuche: 1. um 14:05 ein Versuch über den WSUS 2. um 14:08 ein Update direkt über Microsoft (mittel automatischer Updates, nicht über den Browser, mit dem geht es!) Zum einen ändert sich der Fehler: beim WSUS ist es 8024400e, über Microsoft 80072efd. Letzterer hat angeblich regelmäßig mit internen Netzwerkproblemen wie Proxys zu tun. Wir setzen auch tatsächlich einen Proxy ein. Dabei fällt auf, dass bei den ganzen Fehlermeldungen immer "Proxy List used: <(null)>" st
  13. Okay, ich hatte gelesen, dass es nur Clients beträfe, die auch ein betreffendes Office-Paket abfragen. Mein Fehler. Das Leeren des Downloadcaches hat leider auch nicht geholfen. Danach verbindet sich der Rechner, lädt auch problemlos und ohne eine einzige Fehlermeldung im Log das Selbstupdate runter, nur um beim nächsten Mal wieder Fehler zu produzieren, wenn es um die "normalen" Updates geht. Interessanterweise sagt der Client auch jedesmal ein Selbstupdate sei nicht nötig, aber als ich ihn testweise mal per Browser direkt mit Windowsupdate verbunden habe kam als erstes ein: Update muss a
  14. Den Hotfix habe ich ausgeführt, da es nicht gebracht hat anschließend auch den Workaround. Danach kam der Fehler an anderer Stelle (simpleAuth.asmx anstatt client.asmx) aber er kam trotzdem. Den Downloadcache habe ich allerdings nicht geleert, werde das mal ausprobieren. Allerdings können sich auch Clients ohne Office2003 nicht korrekt mit dem Server verbinden. SP2 habe ich noch nicht installiert, da es als "beta" gekennzeichnet ist und ich keine Testumgebung habe. Auf dem Produktivsystem wollte ich es so nicht aufspielen.
  15. hier Meldungen zwei und drei: 2009-09-01 08:53:18.531 UTC Error w3wp.5 ClientImplementation.SyncUpdates System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.UpdateServices.Internal.DataAccess.ExecuteSpGetCoreUpdateXml(Int32[] revisionIds) at Microsoft.UpdateServices.Internal.DataAccessCache.GetCoreUpdateXml(Int32[] revisionIds, DataAccess da, Int64 maxXmlPerRequest) at Microsoft.UpdateServices.Internal.ClientImplementation.GetSyncInfo(DataAccess dataAccess, Hashtable stateTable, Hashtable deploymentTable, Boolean haveGroupsChanged, Boolean
×
×
  • Create New...