MiLLHouSe

Nein, ganz sicher nicht. iCloud habe ich auch nur testweise auf meinem Gerät hier installiert, um dies zu testen. Und ich verwende iCloud schon seit >10 Jahren und in der jetzigen Firma bin ich erst seit 05/23 und muss beruflich leider ein Android verwenden ; ) . Danke aber für den Tipp mit den Überwachungsrichtlinien, das muss ich dann wohl mal genauer anschauen, denn die Richtlinie "Anmeldeereignisse überwachen" ist bei uns sowohl bei Erfolg als auch bei einem Fehler aktiviert.

@NilsK Ganz einfach. Jedes mal, wenn ich iCloud starte, geht mein Zähler aus mir unerklärlichen Gründen hoch. Das kann ich so nachstellen und "funktioniert" jederzeit. Ich habe jetzt unseren Kontosperrungscounter auf 10 gestellt, somit wird das Konto nicht mehr gesperrt, da der Zähler nach 10 Minuten wieder zurückgesetzt wird (war vorher auf 30 Minuten). Höher als 6 habe ich es bislang nicht geschafft und somit passt das dann auch. In unserer Sophos musste ich noch den kompletten IP-Bereich von Apple (17.xxx/8) freigeben und als Regel vom LAN ins WAN definieren. Danach ging die Anmeldung, aber eben mit dem benannten Effekt. @cj_berlin 1. In den Eventlogs finde ich absolut keinen Eintrag auf die Kontosperrung, das ist ja das, was ich noch zusätzlich total seltsam finde. Mein Rechner war z.B. mit unserem DC1 verbunden und der Zähler ging am DC3 auf 5 und hat mein Konto gesperrt. Das ist jetzt auch noch so, jedoch ist jetzt die maximale Anzahl an Fehlversuchen auf 10 eingestellt und somit reicht das. 2. Ja die ist aktiviert, jedoch läuft mein Passwort nicht aus und betrifft mein AD-Konto auch nicht. Ich verstehe halt einfach nicht, warum der Zähler hoch geht, wenn ich meine privaten Anmeldedaten in die iCloud-Anwendung unter Windows eintrage und mich anmelde.

Ja, das ist ist wieder ein anderes Thema, richtig. Hat der vorherige Admin so eingetragen und muss noch in der Abteilung besprochen werden. Aber es ist schon komisch... Wir haben 3 DCs. Der Zähler geht am dritten DC hoch, zieht den "PDC" mit hoch. Der geht zwischenzeitlich durch eine korrekte Anmeldung wieder auf 0, doch der dritte bleibt auf derzeit 4. Melde ich mich nun wieder bei iCloud an, geht der Zähler auf 5. Jede Anmeldung verursacht zwei Fehlversuche, das konnte ich schon feststellen. Also drei Logins und das AD-Konto ist dicht. Mein Konto/Rechner ist aktuell mit dem ersten DC verbunden, vermutlich geht deshalb dort auch der Zähler nach kurzer Zeit wieder auf 0.

Hallo zusammen, ich habe ein extrem komisches Phänomen/Verhalten. Auf meinem Firmen-PC (Win11) habe ich testweise iCloud installiert, da unser GF das verwenden will/muss/... und es nicht funktionierte, da die Firewall das geblockt hatte. Nun habe ich das Problem, dass mit Anmeldung autmatisch der Counter hochgezählt wird, dass ein falsches AD-Passwort für meinen Benutzer eingegeben wurde. Bei uns ist eingestellt, dass bei fünf Fehlversuchen das Konto gesperrt wird. Das habe ich heute schon 4x hinbekommen (gestern 2x), ohne dass ich bis zum dritten mal wusste, woher es kommt. Erst dann habe ich einen Zusammenhang mit iCloud f. Windows und der Sperre hergestellt und konnte das auch nachvollziehen, dass der Zähler mit Anmelden an der App hochgezählt wird bis zum count 5, dann ist das AD-Konto dicht. Im Ereignislog des DCs steht davon nichts, kein Eintrag, dass das Konto gesperrt wurde. Ich habe ehrlich gesagt absolut keinen Plan, wie das zusammenhängen soll, sprich mein AD-Konto mit der iCloud-App und meiner privaten Apple-ID, aber es ist definitiv nachvollziehbar und genau so. Hat jemand eine Idee, was das bitte sein soll? Es wäre nur dumm, wenn der GF nun hergeht und sich anmeldet und ihm ständig sein Konto gesperrt wird. Wie soll ich ihm das erklären? Das ist doch nicht logisch oder? Gruß Alex

Hallo zusammen, das Skript scheint weiterhin gut seinen Dienst zu leisten. Mir ist nur gerade was aufgefallen, was ich nicht weg bekomme: Neuer PC mit Windows 11, Outlook (new) ist vorinstalliert und an das Startmenü angeheftet. Nun läuft das Skript bzw. die Aufgabenplanung und deinstalliert das Programm. Nur leider bleibt die App am Startmenü angeheftet und kann nun vom Benutzer angeklickt werden. Tut er das, wird das Programm tatsächlich wieder installiert und gestartet. Im eigentlichen Programmmenü, wo ich alle installierten Apps/Programme sehe, ist es raus, es hängt also "nur" angeheftet im Startmenü. Gibt es eine Chance, dass man dies dort auch noch mit weg bekommt? Das ist ja schon echt bescheiden so. Nachtrag: Nun scheint es wohl doch (wieder) zu funktionieren. Ich habe es nun nochmal mehrfach getestet, nun wird auch die Verküpfung im Startmenü wieder gelöscht. Muss ich mal noch weiter beobachten, aber ist schon seltsam...

Schau mal hier mit rein klick Ich habe gestern eine ähnliche Anfrage hier gestartet und dies heute abschließend gelöst bekommen, indem ich das per GPO und einem geplanten Task ausführen lasse (Outlook). Da wird bei jeder Anmeldung des Benutzers das Skript ausgeführt und Outlook deinstalliert. Das Skript kann man ja beliebig erweitern. Vielleicht hilft es dir ja weiter.

Und ich habe festgestellt, dass die Aufgabe beim Anmelden tatsächlich läuft, ohne dass man davon was sieht. Ich habe sie vorhin nur testweise manuell ausgelöst und da hatte ich kurzzeitig das Fenster gesehen. Also so sieht es jetzt erstmal sehr gut aus und ich bedanke mich ganz herzlich bei euch für die großartige Unterstützung.

Theoretisch ja, aber wir verwenden bei uns das Logon-Skript nicht. Es läuft alles komplett über GPO. Ich könnte jetzt natürlich das dafür hernehmen, aber ich hätte es dann doch ganz gerne einheitlich und entsprechend unserer internen "Vorgabe" (wenn möglich). [edit] Es läuft jetzt. Ich habe die Aufgabe als benutzerdefinierte GPO erstellt und in dieser bei Benutzer folgendes eingetragen: %USERDOMAIN%\%USERNAME% Damit kann ich die Aufgabe ausführen und das Outlook wird deinstalliert :) Schön wäre zwar, wenn nicht kurzzeitig die Ausführung von Powershell angezeigt würde, aber das lasse ich mir da mal eingehen und sollte niemanden stören.

Ich habe den Task mal als Administrator ausführen lassen, da kommt dann die Meldung: Removing Packages... AUSFÜHRLICH: Ausführen des Vorgangs "Paket entfernen" für das Ziel "Microsoft.OutlookForWindows_1.2023.1108.0_x64__8wekyb3d8bbwe". Remove-AppxPackage : Fehler bei Bereitstellung. HRESULT: 0x80073D19, Fehler aufgrund der Abmeldung eines Benutzers Microsoft.OutlookForWindows_1.2023.1108.0_x64__8wekyb3d8bbwe kann nicht entfernt werden, da der aktuelle Benutzer dieses Paket nicht installiert hat. Verwenden Sie Get-AppxPackage, um die Liste der installierten Pakete anzuzeigen. Wenn ich selbst einen Task erstelle, steht ja mein Benutzer drin, der die Aufgabe ausführen soll. Doch wie kann ich das per GPO mitgeben, dass der dann aktuell angemeldete User verwendet wird? Der User ist ja u.U. auch mehrfach am Tag unterschiedlich, wenn sich da mehrere Benutzer an- und abmelden.

OK, das hast du wohl geschrieben... Aber wie kann ich das über die GPO mitgeben, dass der angemeldete Benutzer verwendet wird? Und was ist, wenn der Benutzer keine lokalen Adminrechte hat? Vielleicht stehe ich da auch gerade einfach nur auf dem Schlauch und verstehe es nicht... OK, Nachtrag: Ich habe jetzt bei $Packages = Get-AppxPackage Microsoft.OutlookForWindows das -AllUsers hinzugefügt und nun steht im Log, dass er ein Paket gefunden hat Die Aufzeichnung wurde gestartet. Die Ausgabedatei ist "c:\temp\skript.ps1.Log". Number of Packages found: 1 Name Version InstallLocation ---- ------- --------------- Microsoft.OutlookForWindows 1.2023.1108.0 C:\Program Files\WindowsApps\Microsoft.OutlookForWindows_1.2023.1108.0_x64... Removing Packages... AUSFÜHRLICH: Ausführen des Vorgangs "Paket entfernen" für das Ziel "Microsoft.OutlookForWindows_1.2023.1108.0_x64__8wekyb3d8bbwe". AUSFÜHRLICH: Vorgang abgeschlossen für: Microsoft.OutlookForWindows_1.2023.1108.0_x64__8wekyb3d8bbwe Nur deinstalliert hat er nix, das Paket ist weiterhin vorhanden.

OK, dann halt über Skripting, wenn es am Ende funktioniert... Ich habe das jetzt mal so verwendet und das Log sagt mir nun folgendes: ********************** nStart der Windows PowerShell-Aufzeichnung Startzeit: 20231116090012 Benutzername: xxx\SYSTEM RunAs-Benutzer: xxx\SYSTEM Konfigurationsname: Computer: NB213 (Microsoft Windows NT 10.0.22631.0) Hostanwendung: c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -File c:\temp\skript.ps1 Prozess-ID: 18872 PSVersion: 5.1.22621.2506 PSEdition: Desktop PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.22621.2506 BuildVersion: 10.0.22621.2506 CLRVersion: 4.0.30319.42000 WSManStackVersion: 3.0 PSRemotingProtocolVersion: 2.3 SerializationVersion: 1.1.0.1 ********************** Die Aufzeichnung wurde gestartet. Die Ausgabedatei ist "c:\temp\skript.ps1.Log". Number of Packages found: 0 No Packages found, nothing to do... ********************** Ende der Windows PowerShell-Aufzeichnung Endzeit: 20231116090012 ********************** Mich wundert, dass er kein Paket gefunden hat und nichts tut. Führe ich Get-AppxPackage Microsoft.OutlookForWindows manuell in PS aus, findet er natürlich das installierte Paket.

Ich hab im Mai die Firma gewechselt. Damit einher ging auch ein Wechsel der Hardware weg von Fujitsu (Clients) und HP (Server) hin zu Dell, die hier ausnahmslos eingesetzt wird. Gute Geräte durchweg. Allerdings kann ich auch nur empfehlen, mind. 16 GB RAM zu nehmen. Spätestens seit Windows 11 sind 8 GB echt grenzwertig, wenn man nen Browser, Office und vielleicht sogar noch Teams offen hat. Da hab ich schon etliche Kisten gesehen, die eine Auslastung von >90% hatten.

Hallo Sunny, ich wollte es auch gerade schreiben, dass ich da ja falsch war und dass es natürlich genau dorthin gehört. Das habe ich mittlerweile schon ausprobiert, aber es klappt weiterhin nicht. Zwar sagt die Aufgabenplanung weiterhin schön brav, dass der Task ausgeführt wurde, nur passiert einfach nichts :( . Anderswo habe ich gelesen, dass man mit dem Befehl "Set-ExecutionPolicy RemoteSigned evtl. weiterkommt. Damit konnte ich dann aber lediglich das ps1-File ohne irgendwelche Parameter in PS aufrufen. Manuell kann ich die Deinstallation durchführen, da gebe ich in einer CMD einfach c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -File c:\temp\PS-Skript.ps1 ein und es läuft. Nur automatisiert nicht. Ich geb's bald auf...

Leider keine Änderung. Das erzeugte TXT sieht weiterhin wie gehabt aus. @BOfH_666 Du meinst als Parameter dann so: -AllUsers -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -File "c:\temp\PS-Skript.ps1" ? Da kommt dann 0x1 bei der Ausführung, also direkt ein Fehler.

Das ist ja mein Problem. Die Ausführung an sich klappt ja, nur eben nicht über die Aufgabenplanung als SYSTEM oder als Benutzer Administrator. Es geht bei mir (mit lokalen Admin-Rechten) und bei manueller Ausführung ohne Probleme. Nur über die Aufgabenplanung (nach Anmeldung und manuell) nicht.