tesso

Die Stripsize im Controller ist immernoch 1MB. teste doch mal die Einstellung von Norbert

Technisch könnte man mit einem externen Timestampserver signieren. Dann wäre die Signatur auch weiterhin gültig. Ich vermute aber ganz stark, daß das nicht gemacht wurde. Edit: rdpsign kennt anscheinend keinen timestampserver.

Leute der Thread ist von 2013. Könnt ihr den nicht einfach ruhen lassen?

@guybrush Ich hatte das testweise auch noch als "encodedcommand" übergeben. Dann sieht man nicht mehr (auf den ersten Blick) was der Code tut.

Anforderung "keine weitere Datei"

Gerade bei mir getestet: powershell -command "Get-ChildItem 'c:\windows' -Recurse | Where-Object {($_.LastWriteTime -lt (Get-Date).AddDays(-7))} | Select-Object FullName, LastWriteTime, @{Name='GB';Expression={ '{0:N0}' -f ($_.Length / 1GB) }}"

@testperson Ich winke mal aus der Bahn zurück.

Welche Office nutzt du? Bei den Keycard Office klappt das so nicht mehr.

Mein letzter Tag Schulung diese Woche. @NobbyaushbDas Notebook geht Morgen zurück an den Hersteller. Kann nicht getauscht werden, daher Gutschrift. Ein neues muß ich noch bestellen.

Der Thread ist über 11 Jahre alt. Lass ihn ruhen und mache einen eigenen Thread auf. Hast du die genannte Lösung schon getestet?

Dazu dann beispielhaft noch die Möglichkeit die .net Installation zu unterbinden. https://support.microsoft.com/en-us/help/3133990/how-to-temporarily-block-the-installation-of-the-net-framework-4-6-1 Für supportete Umgebungen würde ich in der SUpport Matrix nachsehen. https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019

Die EWS API ist nur eine API über die du auf die EWS Schnittstelle zum programmieren dieser Schnittstelle zugreifst. Der Exchange nutzt die nicht selbst. Daher ist es sehr unwahrscheinlich, das die API für eine Instabilität verantwortlich ist. Ich habe die nur mal auf einem Testsystem direkt auf dem Exchange installiert, der hatte danach keine Probleme. Problematisch sind eher neuere .net Versionen, wenn der Exchange noch nicht das entsprechende CU hat. Und natürlich auch alles Richtung (falsch oder nicht konfigurierte) Virenscanner. Dazu noch alles was in den Nachrichtentransport eingreift.

Warum willst du die EWS Api auf dem Exchange installieren? Ich installieren an einem Client/Server, der dann die Skripte ausführt.

Hast du denn in der Imap Konfiguration auch Port 993 und SSL/TLS eingestellt?

Active Desktop oder wie immer das heute heißt ist deaktiviert?

Ich erinnere mich dunkel ähnliche Probleme gehabt zu haben. Versuch mal das Bild in den Wallpaper Ordner zu legen und dieses zu benutzen. Ich meine dann ging es.

Dann lautet die ITIL konforme Problemlösung: IGNORIEREN

Jetzt werden wir OT. Mal sehen was der TO zu meinem Vorschlag meint.

Gibt es Unternehmen die das nicht haben? *duck und wech*

Dem Fehlerbild nach müsste das der Server selbst sein. Der Server versucht sich in seinem DNS zu registrieren der vermutlich noch nicht läuft. Sollte der Fehler nur beim Boot auftreten kannst du ihn irgnorieren. Oder du lässt den ersten DNS Eintrag des Servers auf einen anderen DC/DNS zeigen (über Kreuz konfigurieren)

Habe ich das Wort Migration irgendwo überlesen?

Das entspricht einem RU15 https://docs.microsoft.com/de-de/Exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019 Du deinem Fehler sollte es im Eventlog Einträge geben. Virenscanner sind immer eine beliebte Fehlerquelle. Evtl. einmal vollständig deinstallieren (nicht nur deaktivieren) mit den Tools des Herstellers.

Welche Versionnummer hat die Store.exe? Die Buildnumber gibt beim 2010er nur das Servicepack

Schau dir mal AGDLP an. Dieses Konzept sollte sich weiter bringen.

Wenn ich dich richtig verstehe sollte doch eine Sammlung reichen. Zugriff auf die Apps über die Gruppen.