Stoertebeker

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 das dokumentieren soll oder ob ich mir gerade zuviel Kopf darum mache und das ein völlig normaler Vorgang ist. Gruß Stoerte*

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.

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 einmal nötig ist mach ich das zur Not noch.

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 eine .pst Datei, in der es seine Datenstruktur, Kontakte, Kalender und Konten verwaltet. Diese liegt unter Eigene Dokumente\Outlook und wird mit dem Profil zusammen auf den Server gespeichert. Von dort gelangt sie bei Anmeldung an einem anderen PC zunächst dort ins lokale Profil und wird von Outlook auch brav verwendet. 2. Für das in der ersten Datei angelegte IMAP-Konto erstellt Outlook eine zweite pst Datei unter \AppData\local\Microsoft\Outlook. Diese wird, da sie unter "local" liegt, nicht ins Serverprofil übernommen, aber beim Anmelden auf einem anderen PC dort lokal angelegt, da ja das IMAP-Konto in der 1. pst Datei definiert ist. Das IMAP-Konto ist auch vorhanden und die IMAP-Ordner werden synchronisiert und es können Mails empfangen werden. Auch die Überprüfung der Kontoeinstellungen (in den Kontoeigenschaften) gelingt ohne Fehlermeldung - Senden und Empfangen - die Testmail liegt anschließend in meinem Posteingang. Was nicht funktioniert ist irgendeine andere als diese Testmail zu senden. Dabei kommt es dann zu der beschriebenen Fehlermeldung. Außerdem heißt die pst Datei nicht <dateiname>.pst, sondern <dateiname> (1).pst

Sehe ich das richtig, dass das bedeutet: Outlook und IMAP? Vergiss es! (zumindest wenn die User nicht fest an einem PC arbeiten)?

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 stehen. Nun wollte ich das ganze System auf IMAP und eine serverseitige Sicherung der Mails umstellen und habe dazu auf einem separaten Server hmailserver als Mailserver installiert, die Clients verwenden Outlook 2010, um sich per IMAP damit zu verbinden. Da Outlook 2010 aber IMAP Datendateien unterhalb des Verzeichnisses AppData\Local\ anlegt werden diese beim Abmelden nicht ins Serverprofil übernommen. Wenn sich ein Nutzer nun an einem anderen Arbeitsplatz anmeldet, wird der IMAP Account zwar in der Kontenliste aufgeführt und die entsprechenden IMAP-Ordner tauchen auch links auf. Beim Versuch, eine Verbindung zum IMAP-Server aufzubauen, kommt aber folgende Fehlermeldung: Hat jemand ne Idee, woran das liegen kann?

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.

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 zusammengesetzt. Stattdessen werden mehrere Teile angezeigt (part x/y). Im Mailtext findet sich dann folgender Header: From: xxx@yyy.de Subject: To: "xyz" <xyz@yyy.de> Date: Wed, 8 Jun 2011 12:07:51 +0200 Message-Id: <201106081207456F.DCSML-S000210000.000074F20198@172.16.10.92> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="DC_BOUND_PRE_<1307527663.000074f20198>" This is a multi-part message in MIME format. --DC_BOUND_PRE_<1307527663.000074f20198> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --DC_BOUND_PRE_<1307527663.000074f20198> Content-Type: application/pdf; name="20110608120743085.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="20110608120743085.pdf" Danach nur noch kodiertes Material. Ich bekomme die Mails weder automatisch noch manuell wieder zusammen und kann die Teile des Attachments auch nicht speichern. Hat wer nen Tipp? Gruß Stoerte*

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.

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.

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 experimentiere dann weiter. Gruß Stoerte*

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)>" steht. Der Proxy ist aber in den Interneteinstellungen konfiguriert. Außerdem irritieren mich die letzten beiden Zeilen des WSUS-Versuchs, in denen steht, dass angeblich 7 events erfolgreich gemeldet wurden. In der WSUS-Konsole steht der PC aber immer noch mit "Noch kein Bericht erstellt". Sunny, danke für alle Tipps bisher und ich hoffe, du kannst damit etwas anfangen. Schönen Gruß Stoerte* PS Das "Zwangsupdate" des WUclients hab ich vorher auch ausgeführt.

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 aktualisiert werden. Woraufhin allerdings lediglich das WGA-Tool aktualisiert wurde. SP2 ist übrigens mittlerweile installiert.

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.

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 doChunking) at Microsoft.UpdateServices.Internal.ClientImplementation.SoftwareSync(DataAccess dataAccess, UnencryptedCookieData cookieData, Int32[] installedNonLeafUpdateIds, Int32[] leafUpdateIds, Boolean haveGroupsChanged, Boolean expressQuery) at Microsoft.UpdateServices.Internal.ClientImplementation.SyncUpdates(Cookie cookie, SyncUpdateParameters parameters) at Microsoft.UpdateServices.Internal.ClientImplementation.SyncUpdates(Cookie cookie, SyncUpdateParameters parameters) at Microsoft.UpdateServices.Internal.Client.SyncUpdates(Cookie cookie, SyncUpdateParameters parameters) at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Web.Services.Protocols.LogicalMethodInfo.Invoke(Object target, Object[] values) at System.Web.Services.Protocols.WebServiceHandler.Invoke() at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest() at System.Web.Services.Protocols.SyncSessionlessHandler.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) at System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception error) at System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData) at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr) at System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr ecb, Int32 iWRType) 2009-09-01 08:53:18.531 UTC Warning w3wp.5 SoapUtilities.CreateException ThrowException: actor = [url]http://ad-server-2003:8530/ClientWebService/client.asmx[/url], ID=ddb357df-b96f-40cb-bfaa-1f5a93169961, ErrorCode=InternalServerError, Message=, Client=? Im iis.log tauchen keine Fehlermeldungen auf.