Jump to content

maddinx6

Members
  • Gesamte Inhalte

    21
  • Registriert seit

  • Letzter Besuch

Letzte Besucher des Profils

800 Profilaufrufe

Fortschritt von maddinx6

Explorer

Explorer (4/14)

  • 10 Jahre dabei!
  • Engagiert
  • Erste Antwort
  • Erster eigener Beitrag
  • Eine Woche dabei

Neueste Abzeichen

0

Reputation in der Community

  1. Wie meinst du das? Ich habe das vorhin nochmal in einer VM nachgestellt. Das Verhalten ist identisch Morgen werde ich nochmal die Registrierung durchschauen, ob man da noch was löschen kann.
  2. In der Anmeldeinformationsverwaltung wird ein Eintrag erstellt, wenn das new Outlook die Einrichtung abgeschlossen hat. Wenn ich jetzt das Konto aus der APP lösche, bleibt dieser stehen. Aber selbst, wenn ich diesen Eintrag nach dem Löschen aus der APP händisch lösche, wird das Konto wieder ohne Kennwort Eingabe eingerichtet und der Eintrag ist wieder da... [Window Title] Generische Anmeldeinformationen löschen [Main Instruction] Möchten Sie diese generischen Anmeldeinformationen wirklich endgültig löschen? [Content] Internet- oder Netzwerkadresse: Olk/PushNotificationsKey Benutzername: Olk/PushNotificationsKey Es handelt sich um Lokale Windows Benutzerkonten.
  3. Hallo Zusammen, ich habe einen einzelnen Rechner „ohne Domain“ mit zwei Benutzerkonten, die jeweils eine eigene Office 365 Lizenz haben. Leider hat sich Benutzer A unter dem Konto von Benutzer B einmalig in der New Outlook APP angemeldet. Seit dieser Anmeldung ist es nicht mehr möglich die Anmeldinformationen zu löschen. Man kann zwar das Konto in der APP löschen aber beim nächsten Starten steht das Konto bereits vorausgewählt drin. Jetzt muss nur noch einmal auf weiter geklickt werden und das Mailkonto wird ohne Kennwortabfrage wieder eingerichtet. Das Konto von Benutzer A wird nicht unter Einstellungen > Konten aufgeführt. Laut einem MS Support Beitrag soll man mittels „olk.exe –clearLocalState“ das Programm einmal zurücksetzen und anschließend deinstallieren. Dann wieder installieren und ohne vorigen Start nochmal „olk.exe –clearLocalState“ ausführen. Das behebt leider das Problem nicht. Ebenfalls nicht geholfen hat dieser Beitrag. The new Outlook stores the mail in the Microsoft cloud and if you use the account in Outlook mobile or Outlook for mac, they share the cloud storage. Removing or resetting the profile in any of the accounts doesn't remove the cloud storage. Saying yes, remove from all devices does. You will need to add it back on all devices. Es gibt keine Abfrage entfernen von allen Geräten. Das Konto von Benutzer A wird auch nicht in den E-Mailkonten aufgeführt. Hat noch jemand eine Idee wie ich die Anmeldeinformationen gelöscht bekomme? Vielen Dank für eure Unterstützung
  4. Ja, zuerst habe ich nur die ost gelöscht und es nochmal versucht mit den Einstellungen auf dem Bild. Anschließend habe ich den Cache Modus rausgenommen. Danach ging es auch noch nicht. Vermutlich, weil die ost Datei nicht automatisch gelöscht wird. Also diese wieder von Hand gelöscht und es ging. Jetzt habe ich den Cache Modus wieder an und die GPO gesetzt. Mal schauen, ob es Morgen damit läuft. Dieser ganze MS Cloud kram ist was die Umsetzung von Änderungen angeht echt schlimm. Mal wird’s sofort umgesetzt und beim nächsten Mal musste man über zwei Stunden warten. Respekt an die die damit täglich arbeiten müssen.
  5. Moin, Ich gehe mal davon aus das du „Freigegebene Ordner herunterladen“ meinst. Das hat leider nichts gebracht. Wenn ich den Cache komplett ausstelle, funktioniert es Mein nächster Versuch wird Cache Modus an und GPO „Zwischenspeicherung freigegebener E-Mail-Ordner deaktivieren“ aktiviert. Vorher wollte ich aber erstmal abwarten das mein Post vollständig runtergeladen ist.
  6. Mich Persönlich betrifft das auch nicht. Ich wollte nur nicht schreiben ein Abteilungsleiter Bei der weiteren Recherche habe ich gesehen das die externe Person bereits auf die erste Mail eine Antwort bekommen hat. *Wäre schön gewesen, wenn ich die Info gleich bekommen hätte… Für die zweite Mail wurde dann anscheinend aus gesendete Elemente die alte Mail genommen und auf antworten gedrückt. Auf diese Mail hat der externe Kontakt dann keine automatische Antwort bekommen. Also steht im Information Store das versender@extern.de bereits eine Antwort bekommen hat. Solange der Information Store nicht neu gestartet wird oder die automatische Antwort geändert bzw. einmal aus und wieder eingeschaltet wird bekommt versender@extern.de keine weitere automatische Antwort. Habe ich das so richtig verstanden? Bezüglich Stellvertreter bzw. senden als hätte ich auch noch eine Frage. Bei einem Postfach habe ich die Berechtigung senden als. Das klappt aus dem owa problemlos. Mit Outlook bekomme ich die Meldung keine Berechtigung. Antwort vom Support, Berechtigung erneut setzen. Das habe ich inzwischen mehrfach gemacht. Einmal hat es für ein paar Stunden anschließend auch mit Outlook geklappt. Habt ihr dafür vielleicht noch einen Tipp für mich wonach ich mal schauen könnte. Vielen Dank für euren Support
  7. Hallo, ich habe gerade ein Verständnis Problem mit der Automatischen Antwort bei Exchange Online. Mir wurde von einer externen Person ein Mail geschickt. Diese wurde vor dem Urlaub leider nicht mehr bearbeitet. Zwei Tage später hat die Person diese Mail nochmal gesendet. Zu diesem Zeitpunkt war eine Automatische Antwort eingerichtet. Die externe Person hat aber keine Antwort bekommen? Andere Mails haben eine Automatische Antwort bekommen laut Nachrichtenablaufverfolgung. Ist das Verhalten normal/standard? Wenn ja kann man das ändern in jede Mail wird beantwortet? Danke Maddin
  8. Wie vermutet ist für den Support das Problem mit dem Hyper-V Server 2019 mit der Installation vom PowerShell 2.0 gelöst… Ich hätte da noch mal eine Frage zu meiner „kurzen“ Fehlerbeschreibung. War das einigermaßen verständlich? Falls nicht hier ein Video des Fehlers.
  9. Das System ist meine Spielwiese. Dafür hätte man sicherlich auch die Eval Versionen nehmen können. Mein eigentliches Problem ist die FLR restore Geschichte. Das mit dem Hyper-V Server hat sich durch die Spielwiese ergeben.
  10. Da stimme ich dir zu. Ich warte gerade auf die Antwort zu meinen Erkenntnissen. Vermutlich kommt als Antwort, das ist ein MS Problem da es auf einer Core Installation ja ohne PowerShell 2.0 läuft… Wichtiger finde ich allerdings das Restore Problem, bei dem die Dateien auf einem anderen Host landen, wie im Job konfiguriert. Dieses Problem besteht bei allen Server Versionen. Mir ist das nur aufgefallen da ich sporadisch Restore Tests der gesamten Umgebung mache. Deswegen landen die VMs in einem privaten Netz.
  11. Moin, Dukels Tipp war die Lösung des Problems. Vielen Dank nochmal dafür. Ich bin aufgrund des Logeintrags „PowerShell 2.0 or later is required“ davon ausgegangen das die installierte 5.1 ausreicht. Merkwürdig ist allerdings das Powershell 2.0 nur beim Hyper-V Server 2019 benötigt wird. Standard und Datacenter mit und ohne Desktopdarstellung benötigen das nicht.
  12. Ist halt eine Testumgebung. Quick and dirty Dieser Meinung bin ich auch. Aber die wollen sich diesem Thema nicht so recht annehmen. Ich bin da schon seit über einer Woche dran mit denen… Mit dem geht nicht auf Hyper-V Server 2019 könnte ich leben. Aber das der Restore einfach in einer anderen VM auf einem anderen Host landet geht meiner Meinung nach gar nicht. Vielen Dank für dein Unterstützung. Das klingt fast zu einfach. Muss ich mir mal anschauen. Ich bin davon ausgegangen das 5.1 passt wegen des Log Eintrags „PowerShell 2.0 or later is required“
  13. Ist etwas länger geworden. Aber hoffentlich verständlich 😉 Hmm, ich habe mich aber mit genau diesem Konto angemeldet via Enter-PSSession -VMName angemeldet?
  14. Ich habe mir zusätzlich eine kleine Testumgebung aufgebaut. Die Domain dieser heißt demo 😉 Hintergrund des ganzen ist ein meines Erachtens gravierender Fehler im File Level Restore (FLR) von Veeam. Ich versuche das mal zu beschreiben. Gesichert wird VM1 auf Host1. Diese wird anschließend auf Host2 zurück gesichert. Das klappt so weit. Die VM1 hat keine verbundene LAN-Schnittstelle auf Host2 zugewiesen bekommen. Wenn ich jetzt ein FLR-Job einer Datei aus dem Backup von VM1 in die VM1 Kopie auf Host2 mache, beginnt der Spaß. In der Veeam Konsole wird der Job als erfolgreich abgeschlossen dargestellt. Datei xyz in VM1 auf Host2 wiederhergestellt. Die Datei wird aber in VM1 auf Host1 geschrieben! Das liegt daran das Veeam beim Restore grundsätzlich immer erst versucht die Datei über Lan direkt in die VM zu schreiben. Wenn jetzt, wie im meinem Fall VM1 auf Host1 antwortet wird in diese zurückgesichert, ohne zu beachten das mein FLR-Job auf Host2 verweist… Wenn VM1 auf Host1 ebenfalls nicht über LAN erreichbar ist, wird er Job wie angegeben abgearbeitet. Hierfür wird dann PowerShell Direct benutzt. Man kann mittels Reg-Key Veeam dazu nötigen PowerShell Direct bevorzugt zu nutzen, um das Fehlverhalten zu umgehen. Leider klappt der Restore via PowerShell Direct grundsätzlich nicht wenn das Host2 OS Hyper-V Server 2019 ist.
  15. Gibt es jetzt doch einen Hyper-V Server 2022 in der kostenlosen Version? Bisher bin ich davon ausgegangen, dass der Nachfolger azure stack hci „Abo Version“ ist. Azure Stack HCI Im Veeam Log bekomme ich diese Fehlermeldung. Kann es evtl. auch etwas mit dem invoke zu tun haben? Cannot connect to VM over PSDirect. Guest Login: [demo\administrator].;Failed to invoke func [Connect]: Unknown error 0x80131500. Unknown error 0x80131500. PowerShell 2.0 or later is required
×
×
  • Neu erstellen...