Vinc211

Habe erstmal eine Reparatur von Office 2019 versucht und alle Datein aus den Appdata/Local und Roaming Ordnern zu Outlook gelöscht ohne erfolg.

Die Mails sind so lange im Postfach und auch in OWA zu sehen, bis die Person sich am Outlook 2019 Client anmeldet. Also muss eine Regel die nicht sichtbar ist für das löschen verantwortlich sein. Server Seite ist auszuschließen.

Im nächsten Schritt wird Office 2019 deinstalliert und Office2021 installiert.

Am 26.7.2022 um 13:20 schrieb Sunny61:

Wird auf das PF mit Exchange Web Services zugegriffen? Mobile Geräte kommen nicht in Frage für den Fehler?

Exchange Web Services nein und Mobile Geräte werden im EAC auch nicht angezeigt. Kein Firmenhandy etc vorhanden. Nur ein Laptop.

Wenn der Laptop aus und ist Outlook nicht angemeldet bleibt die Mail im Postfach. Also muss es ein Client ereigniss sein. Outlook mit /cleanrules /cleanserverrules und /cleanclientrules zu starten hatte nur keinen Erfolg (Es sind keine Regeln vorhanden gewesen nach Neustart)

Das Auditlog habe ich mit der Anleitung korrekt eingestellt. Trotzdem nur die Erkenntnisse die ich gezeigt habe.

AuditEnabled     : True
AuditLogAgeLimit : 90.00:00:00
AuditAdmin       : {Update, Move, MoveToDeletedItems, SoftDelete, HardDelete, FolderBind, SendAs, SendOnBehalf, Create, UpdateFolderPermissions,
                   UpdateInboxRules, UpdateCalendarDelegation}
AuditDelegate    : {Update, SoftDelete, HardDelete, SendAs, Create, UpdateFolderPermissions, UpdateInboxRules}
AuditOwner       : {Update, Move, MoveToDeletedItems, SoftDelete, HardDelete, UpdateFolderPermissions, UpdateInboxRules, UpdateCalendarDelegation}

Ich werd Outlook jetzt neu installieren.

Ich habe nun Exchange 2019 auf CU12 geupdated da ich gelesen habe das dies die MailboxAudit Probleme beheben soll.

Den Befehl den @massaraksch vorgeschlagen hat konnte ich auch nun erfolgreich ausführen und bekomme folgende Ausgabe:

Leider ist dort nicht mit HardDelete in zusammenhang mit Emails zu sehen. Ich habe meine Testmail um 10:11 geschickt und diese wird dort nicht aufgeführt. Ich habe mir das Postfach wie gesagt verbunden und kann sehen wie die Mail ankommt und direkt wieder verschwindet.

Noch eine Idee? Generell dachte ich man sieht mehr im Auditlog, bzw. alle aktionen. Hab ich wieder was falsch eingestellt?

[PS] C:\Windows\system32>Search-MailboxAuditLog -Identity user@domain.de -LogonTypes Admin,Delegate -StartDate "07/20/2022" -EndDate $Today -ResultSize 2000

RunspaceId               : 3affaba8-176c-4121-85c1-7111d0c8bf5b
MailboxGuid              : a9741d88-d112-4861-b112-ce71a054aa0f
MailboxResolvedOwnerName : username
LastAccessed             : 22.07.2022 12:04:08
Identity                 : domain/MyBusiness/Users/business/username
IsValid                  : True
ObjectState              : New

okay. soweit bin ich gekommen. ich sehe auch unter Get-Mailbox user@domain.de | Get-MailboxFolderStatistics -FolderScope RecoverableItems | fl name,foldersize  das ein Ordner mit Audtis hinzugefügt wurde und jetzt 35Kb hat. Es sieht einfach noch nicht korrekt aus. Wirklich sehr ungeil von MS aber was hab ich erwartet.

/cleanrules hatte keinen effekt. Problem besteht immernoch.

Aktuell habe ich versucht das audit log zu aktivieren und bin dann darüber gestolpert das dies nicht auf Deutschen Servern funktioniert.

Zitat

http://cloudexchangers.com/search-mailboxauditlogs-issue-in-exchange-2019/

Ist dies korrekt oder mach ich etwas falsch. Get-Mailbox user@domain.de | Format-List Audit*     sagt es ist aktiviert, aber mit search-mailboxauditlog bekomme ich keine ergebnisse.

Im EAC ist kein Gerät unter "mobile Geräte" eingetragen. IMAP und POP3 sind deaktiviert. Nur Mapi ist aktiviert.

Im Outlook des Users sind keine weiteren Regeln zu finden.

Neue Erkenntnisse: Die Mails die ich am Donnerstag vom Scanner an das Postfach geschickt habe sind heute wieder nur unter "gelöschte Elemente wiederherstellen" zu finden. Neue Mails vom Scanner werden ebenfalls direkt wieder dorthin geleitet. Also als wenn eine Postfach-Regel das ganze Postfach durchsucht und die Mails wieder verschiebt.

Audit-log werde ich nun testen.

Okay, es funktioniert wieder zumindest für die Mails die ich reproduzieren kann. Ich hatte den Junk E-Mail Filter einmal deaktiviert und dann eine Mail geschickt und Sie kam an.

Nun hab ich den Junk E-Mail Filter wieder aktiviert und die Mail kommt weiterhin an. In der Ausgabe von get-mailboxjunkemailconfiguration ist die Absenderadresse aber vorher wie nachher nicht drin gewesen. Wie bereits gesagt gibt es keine Custom Regeln

vor 41 Minuten schrieb NorbertFe:

Shift Del? ;)

Sehr lustig aber nicht hilfreich. Der User ist gar nicht anwesend und ich habe aktuell die Kontrolle über das Postfach um das Problem zu lösen.

vor 18 Minuten schrieb LukiHoer:

Ok.

Aber wieso letzte Option? 

 

Aber mal ne ganz dumme Frage. Unter "Gelöschte Elemente wiederherstellen" auch schonmal geschaut oder?

Ich habe natürlich in gelöschte Elemente geguckt und gelöschte Elemente wiederherstellen war ausgegraut. Allerdings über OWA konnte ich diese aufrufen und habe die Mails dort gefunden. Aber wie kommen diese direkt dahin. Unternehmsweit werden die Mails aus dem Ordner "Gelöschte Elemente" erst nach 30 Tagen gelöscht und dann für die Wiederherstellung noch vorgehalten.

Okay jetzt muss ich den Prozess finden der diese Mails direkt purged. hmm

Also bist jetzt ist es zumindest der einzige von 100 Usern der den Fehler gemeldet hat.

Die Exchange Datenbank sieht soweit gut aus. Laut Compliance Search ist die Email ja auch im Postfach vorhanden. Postfach neuerstellen wäre für mich die letzte Option wenn es keine wirkliche Lösung des Problems gibt.

1. Ich habe Zugang zum Account. Habe den User komplett aus der gleichung entfernt und Zugang zum Account.

2. Alle Tests wurden ebenfalls im Owa gemacht und dort nicht sichtbar.

Ich habe beim User bereits den offlince sync cache gelöscht und auch abgeschaltet. Die lokale .ost Datei ist nicht das Problem.

3. Ich habe das Postfach bei mir im Outlook eingebunden und die Ansichten zurückgesetzt. Mail trotzdem nicht auffindbar.

Okay,

ich habe mit get-inboxrule -inculdehidden nur 2 deaktivierte und die standard Junk Mail Rule gefunden. Im Junkmail Ordner ist aber nichts. In Gelöschte Mails auch nicht.

Eine Suche über das gesamte Postfach bringt keine Treffer. Sowohl Owa als auch Outlook.

Ich habe ein Compliance Search über das EAC gemacht (Über Powershell ist das ja nur ätzend) und dort finde ich die Mails. Heißt also Sie sind im Postfach? Soweit so gut?

Ich habe die Outlook Protokollierung bei Problemen aktiviert und alle logs die dabei in AppData/local/Temp genertiert wurden gespeichert. Darunter .etl Dateien die sich zwar mit der Ereignisanzeige öffnenlassen. aber dann nichts anzeigen. Weiß leider nicht was ich dort falsch mache. Berechtigungsproblem?

Guten Tag,

bei einem Benutzer kommen manche Mails nicht im Postfach an.

Im Exchange Trackinglog sieht das ganze so aus:

Server1
Timestamp              EventId          Source        Sender                             Recipients                        MessageSubject
---------              -------          ------        ------                             ----------                        --------------
13.07.2022 14:25:51    HAREDIRECT       SMTP          P0005@domain.de                       {usershort@domain.de, vorname.nachname@x... Internet Fax Job
13.07.2022 14:25:51    RECEIVE          SMTP          P0005@domain.de                       {usershort@domain.de, vorname.nachname@x... Internet Fax Job
13.07.2022 14:25:51    RESOLVE          ROUTING       P0005@domain.de                       {vorname.nachname@domain.de}          Internet Fax Job
13.07.2022 14:25:51    AGENTINFO        AGENT         P0005@domain.de                       {vorname.nachname@domain.de, julia... Internet Fax Job
13.07.2022 14:25:51    SEND             SMTP          P0005@domain.de                       {vorname.nachname@domain.de}          Internet Fax Job

Server2
Timestamp              EventId          Source        Sender                             Recipients                        MessageSubject
---------              -------          ------        ------                             ----------                        --------------
13.07.2022 14:25:51    DELIVER          STOREDRIVER   P0005@domain.de                       {vorname.nachname@domain.de}          Internet Fax Job
13.07.2022 14:25:51    HARECEIVE        SMTP          P0005@domain.de                       {usershort@domain.de, vorname.nachname@x... Internet Fax Job
13.07.2022 14:27:46    HADISCARD        SMTP          P0005@domain.de                       {usershort@domain.de, vorname.nachname@x... Internet Fax Job

Das externe Email Archiv arbeitet mit dem journal user von exchange und archiviert die Mail ganz normal.

Get-Mailboxstatistics zeigt an das der ItemCount steigt und die Mailbox größer geworden ist.

Get-Inboxrule zeigt keine automatischen Regeln die angewendet werden an.

Der Fehler ist beliebig reproduzierbar. Zuerst war es eine Mailadresse von einer externen Person und jetzt ist es auch bei einem Scan-to-mail prozess aufgefallen.

Verwendet werden zwei Exchange 2019 15.2 ‎(Build 858.5)‎ Cu9 mit DAG. Client ist Outlook 2019. Owa zeigt die Mail ebenfalls nicht an.

Vielen Dank im vorraus.

Das Problem ist nur das man dann keine genaue Firewall freigabe machen kann.

Wie lösen andere denn das Problem die Server und Client Netz getrennt haben, aber PXE nutzen wollen?

Guten Tag,

ich habe im Zuge der Trennung von Client und Server Netz heute den WDS auf dem auch DHCP läuft in das Server Netz verschoben.

Per ip helper-address im Switch funktioniert die DHCP Zuweisung. In der Firewall wurden die Ports 67, 68, 69, 389 und 4011 UDP und 389 TCP freigegeben.

Beim Start von PXE Boot bekomme ich eine IP Adresse aus dem Client Netz und danach wird in der Firewall angezeigt das eine Verbindung vom Client mit TFTP zum Server aufgebaut wird.

Danach versucht der Server auf einem Highport ( 50000-60000 ) dem Client zu kontaktieren auf einem Random Low Port ( 1000 - 2000 ).

Auf welchem Windows Phänomen bin ich hier gestoßen. Die Ports die bis jetzt versucht wurden zu kontaktieren sind 1158, 1179, 1408, 1425, 1428, 1687 und 1928. Alle UDP.

Kennt jemand dieses Problem?

vor einer Stunde schrieb BOfH_666:

 

ja klar ... aber das willst Du ja offenbar nicht. GPUpdate.exe lässt sich ja direkt starten. Aber es ist eben ein Konsolen-Programm.   ... was ist denn so schlimm daran, wenn das Konsolen-Fenster kurz auftaucht. Darf der Anwender das nicht sehen?

Anwender halt. Ich sehe jetzt schon die Anrufe und Tickets mit einem komischen Programm was sich immer startet und 100 Leute "VIRUS" schreien =D

vor einer Stunde schrieb winmadness:

@Vinc211 Du kannst auch eine Verknüpfung auf gpupdate.exe anlegen und in der Aufgabenplanung als "Programm" zum Ausführen eintragen. In den Eigenschaften in der Verknüpfung kannst Du dann auf dem Tab "Verknüpfung" die Option "Ausführen" auf "Minimiert" setzen. Damit wird kein CMD Fenster angezeigt. Lediglich in der Taskleiste ist ein Eintrag während der Ausführung zu sehen.

Trotzdem versuche ich das mal.

Seltsam finde ich es trotzdem das in diesem Fall eine 100% Silent Lösung noch nicht gefunden wurde. Wenn der blöde VPN Client sich Pre-Logon verbinden würde, wäre das Problem gar kein Thema.

Die Task Lösung war schon das eleganteste was ich für die HomeOffice gpupdate Problematik gesehen hab.

Gerade eben schrieb BOfH_666:

 

Nur damit ich das nicht vielleicht falsch verstehe ... das Script führt nur diesen einen Befehl aus?

korrekt. gibts über die Aufgabenplanung eine Lösung das komplett ohne SKript zu machen?

Gerade eben schrieb BOfH_666:

 

Wenn man die Option aktiviert, kann man auswählen, welche Netzwerkverbindung verfügbar sein muss.  ... ob das zielführend ist, hängt natürlich davon ab, was der Grund dafür ist, dass das Script nicht erreichbar ist ... warum ist das Script eigentlich nicht erreichbar? ... und wäre es dann nicht besser, es einfach lokal vorzuhalten?   

 

 

Dann eben ein lokales VBScript, welches die Verfügbarkeit prüft!?  

 

Vielleicht gibt es aber auch eine ganz andere / viel bessere Lösung für Dein Problem ... was ist denn die eigentliche Aufgabe des Scripts, wenn das nicht geheim ist?   

Das Script liegt auf einem Server und soll gpupdate /force ausführen. Es wird von ereigniss 10000 im Ereignisprotokoll getriggert welches für Verbindung wurde hergetsellt steht. Damit sollen Personen im Home Office die sich per VPN einwählen, nach der VPN einwahl ein gpupdate bekommen. Funktioniert soweit ganz gut. Allerdings möchte ich das Script nicht auf jeden Rechner kopieren.

Das Problem tritt auf wenn jemand zuhause seinen Laptop benutzt und z.b. von WLAN auf LAN wechselt. Der Trigger wird dann ebenfalls angestoßen. Da die Aufgabe über eine GPO kommt kann ich auch nicht genau den Adapter auswählen, sonst wäre die Lösung natürlich gut.

vor 56 Minuten schrieb BOfH_666:

Wie wäre es, wenn Du die Aufgabe nur ausführen lässt, wenn die Netzwerkverbindung auch verfügbar ist? ... kann man einstellen ...  

Man kann nur sagen "Wenn alle Verbindungen verfügbar sind" und sonst nichts.

vor 25 Minuten schrieb Sunny61:

Alternativ die Aufgabe mit einer Batch starten und darin prüfen ob der UNC-Pfad erreichbar ist. Wenn ja, VB-Script ausführen, ansonsten schlafen legen. ;)

Wir sind extra von einer Batch weg, weil diese ein cmd Fenster öffnet.

Guten Tag,

ich hoffe die Frage gab es nicht schon 100mal, ich habe zumindest keine Antwort dafür gefunden.

Ich lasse über die Aufgabenplanung ein vb Skript laufen bei einem bestimmten Trigger. Das Skript liegt nicht lokal sondern auf einem Server.

Es kann sein das die Aufgabe ausgeführt wird während das Skript nicht erreichbar ist und dann kommt die Meldung vom Windows Script Host: Das Laden des Skripts "UNC Pfad" ist fehlgeschlagen (der Netzwerkpfad wurde nicht gefunden).

Der User muss das mit "OK" bestätigen.

Frage: Gibt es eine Möglichkeit diese Abfrage / Fehlermeldung abzuschalten?

Vielen Dank

Gerade eben schrieb NorbertFe:

Dann ist ja gut. Der Zweck von dfs besteht für mich üblicherweise in der Servernamenunabhängigkeit. Wenn die User sich daran aber gewöhnen, daran links anlegen usw. usf., Rate mal was dann beim nächsten serverwechsel passieren wird ;)

Der user Kreis der den Workaround nutzt ist relativ klein.

Wenn das DFS Probleme macht muss man ja irgendwas bereitstellen damit die Leute an ihre Daten kommen. Oder möchtest du sagen das die Freigaben ein Teil des Problems sein können?

vor 1 Stunde schrieb Weingeist:

Wie gesagt, erstelle ein Script unter C:\Scripts oder so welches das was per GPO ankommt neu macht. Sprich Netzlaufwerk trennen + wieder neu verbinden. Oder auch unter dem Netlogon-Share. Wenn etwas falsches zwischengespeichert ist, bekommst ein Netzlaufwerk selten wieder einfach so geradegebogen. Zumal immer noch die Frage ist, ob es nur neu erstellt wird per GPO wenn nicht bereits vorhanden (auch wenn falsch) oder komplett ersetzt wird. Wird es nicht ersetzt, dann gibt genau der eigene Work-Around nachher probleme wenn sie einen spezifischen Fileserver angeben jedoch nicht immer der gleiche verfügbar ist.

--> Daher mache ich das normal per Script (auch wenn per GPO ausgelöst oder Startup), dann bin ich sicher das es getrennt und neu verbunden wird und so mancher Ärger erspart wird.

Ich werde es das nächste mal ausprobieren, aber es löst das Problem nicht.

Der VPN wird erst nach dem Start von Windows gestartet, also werden Startup-skripte von NETLOGON oder GPO's nicht ausgeführt.

Alle Server sind dauerhaft verfügbar.

vor 1 Stunde schrieb NorbertFe:

Das Problem ist aber jetzt schon erkennbar welches sich daraus ergibt, oder? ;)

nein. ich sehe das problem mit den freigaben nicht.

vor 1 Minute schrieb Weingeist:

Einfach mal alle möglichen Varianten durchtesten, was anderes bleibt dir nicht übrig. Dazu mit Wireshark analysieren.

1. Laufwerk eben nicht per GPO verbinden sondern wirklich erst wenn VPN voll da ist und Im Netzwerkadapter das Netzwerk angezeigt wird die Verbindung erstellen.

2. Eine Stufe retour, also Laufwerk nicht trennen, neu starten und schauen ob es nach VPN Aufbau wieder tut

3. Wieder eine Stufe retour, Laufwerk trennen, neu starten, manuell verbinden (versuchen), VPN aufbauen schauen obs tut

4. manuell trennen, manuell neu verbinden entweder direkt per Kommandozeile oder testweise erst im Explorer

 

So kriegst evtl. einen Work-Around hin der möglichst ohne Adminrecht und Neustart tut. Damit erstellst ein Script (sofern möglich und das Problem behebt), damit es der User selbst tun kann. Link auf das batch auf den Desktop. (Also Trennen und neu verbinden)

 

 

Falscher Namespace: Nun da kommen wir der Sache schon etwas näher ;)

Schuss ins blaue: Ihr habt zwei aktive DFS-Ziele aber nur eines ist per VPN erreichbar. Arbeitet er am anderen Standort, bekommt er entweder Zugriff auf beide Ziele oder auf genau ein anderes. Im Cache ist aber der Pfad zum "falschen" hinterlegt. Da verbundene Netzlaufwerke so gut wie nie - oder mir nicht erkennbaren System - aktualisiert werden, funktioniert der Zugriff nicht.

 

Aber von unterschiedlichen Sites und Standorten habe ich ehrlich gesagt keine Ahnung. Da ich nur kleine Umgebungen habe, versuche ich auch mehrere Standorte unter einen AD-Standort zu kriegen und die Leute per Fernzugriff auf das Hauptsystem arbeiten zu lassen. Sprich Jumphost Prinzip und möglichst Keep-it-simple. Ansonsten muss dann ein anderer ran.

Wir haben einen funktionierenden Workaround etabliert. Die User wissen das wenn das Laufwerk nicht per klick erreichbar ist Sie \\domain.loc oder \\fileserver.domain.loc eingeben können um die Daten zu erreichen. Manche haben sich da als Network share bereits eingerichtet. Aber das ist ja nicht Ziel oder Sinn des ganzen.

in den DFS Einstellungen kann man die Ziele ja selbst aktiv schalten und überprüfen. Alle Personen die sich per VPN anmelden bekommen in der DFS übersicht des laufwerks den richtigen share zugewiesen. Wechseln und überprüfen funktioniert auch, bringt aber nichts.

vor 1 Minute schrieb Forseti2003:

Anderer Ansatz wäre das VPN-Gateway, hat das vielleicht eine Policy/NAT-Routing aktiv die da ein Problem verursacht?

Verstehe nicht wie ein temporäres Problem bei einem Prozentsatz von leuten durch eine permanente Regel ausgelöst werden soll.

Wir haben eine Sophos UTM 9.7 mit dem Sophos Open VPN Client der die routen bei route.exe add setzt.

Das es dort manchmal zu DNS Problem kommt weiß ich, wie gesagt mit VPN neustart sind die dann behoben.

Auf meiner Suche im www bin ich übrigens auf einige gestoßen die das selbe Problem wie ich beschreiben, nur gabs da meistens keine Antworten drauf und keine Lösungen. Ich befürchte es ist MS hokus pokus.

vor 17 Minuten schrieb Weingeist:

So wie es aussieht scheitert er schon ziemlich früh. Ohne den Rest gesehen zu haben würde ich sagen, er findet den Pfad im Cache, will auf diesen zugreifen, kann aber den Domänen-Namen nicht auflösen.

 

Mögliches Problem:

- Keine saubere DNS-Auflösung in jenem Moment wo die Verbindung aufgebaut werden soll.

- Noch keine aktive Domänenzugehörigkeit (Sichtbar beim Netzadapter)

- Anderes Sicherheitstoken das nicht mehr gültig ist sobald er sich mit VPN einklinkt, die Verbindung hat er eventuell mit einem alten versucht aufzubauen, was dann scheitert.

-->laufwerke trennen und neu verbinden nachdem ein manueller Zugriff geklappt hat. Das gleiche auch mal nach einem Neustart und erst verbinden wenn VPN aufgebaut ist (das meinte ich mit alles rauskicken)

- Netzwerkprobleme --> Zu viel Paketloss --> Sicherheitstoken macht Ärger bzw. der Client verliert das Vertrauen des AD, dabei wird es bei verbundenen Netzlaufwerken gar nicht oder nicht sofort wiederhergstellt. Manueller Zugriff funktioniert dann meistens trotzdem, aber nicht zwingend stabil. (Hier hier es mal funktioniert indem ich die Geschwindigkeit gedrosselt habe, ist aber via VPN wohl eher tricky)

- Möglicherweise gibt es auch Ärger wenn das Netzlaufwerk via einem anderen Adapter aufgebaut wird, also einmal WLAN und dann LAN oder VPN-Adapter. Dann könnte es sein, dass irgendwo eine definierte Route gecached ist, die dann fehlschlägt.

 

EDIT: Hier findest den Ablauf einen DFS-Requests: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dfsc/1ff7d611-ba19-49fb-95f4-7c5358b86834

 

Aber eben, hier hilft vermutlich am Ende nur systematischen vorgehen, ausprobieren...

Habe pings laufen und nslookup in allen variationen getestet während ich das laufwerk anklicke. DNS kanns nicht sein.

Domänenzugehörigkeit ist da und soweit ich weiß kann diese doch nicht einfach im laufenden Betrieb verschwinden wenn man nichts am Netzwerk / VPN macht.

Das Laufwerk wird per GPO verbunden. Ich habe auch schon das Laufwerk entfenrt und bei bestehender Verbindung gpupdate durchgeführt doch der Fehler blieb bestehen. Manuell hab ich es glaube ich noch nicht versucht.

Paketloss schließe ich auch aus, da die Remoteverbindungen und Datei-Downloads über Workarounds ohne Probleme klappen.

Kollegen sind zuhause alle im WLAN und und dann per VPN Verbunden. Wie gesagt funktioniert es bei manchen dann einfach en VPN neuzustarten und dann gehts, bei manchen nicht.

Was mir auffällt ist das die Antworten im Wireshark nicht vom "nächsten" Namespace kommen sondern von einem anderen Standort. Die User kriegen per VPN eine IP die ich in AD Standort und Dienste der Default First Site zugewiesen habe, doch die antwort auf nslookup domain.loc und die Antwortem im Wireshark kommen alle auf einem Standort und nicht vom DC und Fileserver der Default-First-Site

vor 1 Minute schrieb Forseti2003:

Hast Du mal Deine DNS-Server geprüft, ob die sich gegenseitig sauber erkennen und die Zoneneinträge übernehmen? Auch mal die Zone prüfen, nicht das versehentlich einige Einträge ins Nirwana führen.

ich kann im DNS keine Probleme feststellen, da alle nslookups und fqdn abfragen sauber laufen. wie gesagt: alle aufrufe funktionieren solange man sie manuell macht, nur der Doppelklick auf das Laufwerk funktioniert nicht.

ich überprüfe nochmal alles im DNS, glaube aber nicht das ich was finden werde.