UKortkamp

Wenn ich für eine Software Geld bezahlt habe (und damit meine ich nicht meine freiwillige PP Spende an den Entwickler) überhaupt keine Frage. Bei einer, ansonsten wirklich genialen, Software die mir viel Arbeit abnimmt und obendrein Free- / Donationware ist, versuche ich es erst "auf diesem Wege". Das Ergebnis dessen (mit dem Hinweis auf Verbesserung) werde ich ihm sicher noch mitteilen. Nochmals vielen Dank an alle, die sich hier mit eingebracht haben.

Da gebe ich Dir durchaus Recht - ein "xxx.DLL" NOT FOUND hätte vermutlich schneller zum Ziel geführt...

Natürlich - das wäre sonst auch der nächste Schritt gewesen. Aber bei dieser Form von Software probiere ich es i.d.R. erst einmal mit "Schwarmwissen" - zumal hier im Forum auch schon Fragen nach RVTools gestellt bzw. beantwortet wurden. Ein reines/echtes Forum zu den RVTools konnte ich leider nicht finden - nächste Anlaufstelle wäre sonst noch das Veeam Forum gewesen, da der Hersteller Sponsor der RVTools sind. Besten Dank und VG

Manchmal hilft es ja auch darüber zu sprechen.... Die besagte DLL befindet sich im RVTools Installationsverzeichnis. Liegt kein Suchpfad auf dem Ordner und man startet die exe mit LW:\Pfad\Pfad\exe findet er sie natürlich nicht -> o.a. Fehler. Beim Doppelklick auf die EXE ist das Working Directory natürlich auf seinem Installationsordner - und damit findet er die DLL. Thema erledigt - und danke an alle, die sich Gedanken gemacht haben

RV Tools ist eine Freeware - mit erstmal keinem Anspruch auf Support. Daher dachte ich mir hier mal auf das Schwarmwissen zu hoffen Stimme ich Dir grundsätzlich zu... DIE wird aber auch angesprochen, wenn man das Tool manuell startet.... und DAS funktioniert ja. Das Problem ist ja hier nur der Aufruf mit Übergabe Server/User/Pass als Parameter -- grundsätzlich habe ich das in anderen Installationen schon mehrfach problemlos genutzt.

Hallo zusammen, _etwas_ OffTopic - hoffe es hat trotzdem jemand eine Idee. Die RVTools dürften vermutlich den meisten, die (auch) mit VMware zu tun haben, ein Begriff sein. Aktuellste Version 4.3.1 installiert. Manueller Start -> Eingabe von <vc-fqdn> <Administrator> <myPass> => kein Problem. Im Batch aufgerufen mittels "RVTools.exe -s <vc-fqdn> -u <Administrator> -p <myPass>" kommt eine Fehlermeldung: Could not connect to <vc-fqdn> Unknown error: STSService.dll Ich habe das inzwischen an 3 Rechnern probiert - der Fehler ist auf allen identisch. Ich hoffe jemand hat eine Idee woran das liegen könnte. Besten Dank und VG Uwe

Danke Euch beiden!

Moin, danke für den Link (hatte ich heute morgen auch schon gefunden). Primär ging es mir um die grundsätzliche Exchange Funktionalität. Dachte ich hätte irgendwas falsch gemacht oder vergessen - aber dann ist es eher ein Bug oder "by Design". Danke und Gruß

Hallo zusammen, wir haben einen (Ausland-) Standort aufgegeben und daher auch 2 (SMTP-) Domains auf unserem OnPremise Exchange 2016 CU23 gelöscht. Die Domains wurden unter "Nachrichtenfluss" -> "Akzeptierte Domänen" gelöscht und anschließend die "E-Mail-Adressrichtlinie" angepasst und "Anwenden" ausgeführt (es gibt nur diese eine Richtlinie). Meine Erwartungshaltung war nun eigentlich, dass bei den Usern die unter "E-Mail-Adresse" den Haken "E-Mail-Adresse basierend... automatisch aktualisieren" gesetzt haben, die SMTP Adressen der gelöschten Domains auch automatisch wieder entfernt werden (wie sie auch beim erstellen seinerzeit hinzugefügt wurden) - dies ist allerdings auch nach inzwischen 48 Stunden nicht passiert. Habe ich da einen Denkfehler? Danke und Gruß Uwe

Hallo zusammen, ich befürchte wäre es ein "genereller Bug" hätten vermutlich schon viel mehr auch "hier" geschrien - so das ich schon glaube irgendetwas spezielles in unserer Installation zu suchen. Gemäß dieser Anleitung hatte ich das mal bei uns überprüft und ebenfalls identisches festgestellt. Der große Witz ist: Für unsere DEMO Notebooks hatte ich (vor einigen Wochen) innerhalb VMware-WS eine solche Installation "from the Scratch" aus aufgebaut und dort heute mal reingeschaut - auch dort finden sich identische AD-Rechte -- und in der Installation war definitiv nie an anderer/älterer Exchange jemals vorhanden. Der große Unterschied ist aber: in der DEMO Umgebung war kein Member-Eintrag in der ExchangeLegacyInterop-Group - in unserem LiveSystem war der MSX-2016er Member. Lange Rede kurzer Sinn: Bis auf 1 Postfach (meines) funktioniert bei allen anderen (momentan) deren Regelwerk (nachdem ich o.a. Rechteänderungen am AD vorgenommen hatte). Ich vermute mal (oder suche noch), das ich mich selbst irgendwann in irgendeine Gruppe eingetragen habe, der das (im Artikel beschriebene) verboten ist. ... finde ich hoffentlich auch noch. Gruß Uwe

und inzwischen auch nach dieser Anleitung vorgegangen um via MFCMAPI ggf. versteckte/defekte Regeln zu finden und löschen - wobei nach manuellem löschen im Outlook auch via MFCMAPI keine mehr zu finden waren....: https://blogs.msdn.microsoft.com/hkong/2015/02/27/how-to-delete-corrupted-hidden-inbox-rules-from-a-mailbox-using-mfcmapi/ Die (meine) Ratlosigkeit steigt...

Siehe oben: Regeln wieder gelöscht und via OWA und/oder Powershell neu angelegt.

Hallo Thomas, Danke für den Tipp - das hatte ich in meiner obigen Aufzählung vergessen (und jetzt ergänzt) - auch "outlook.exe /cleanrules" bzw. /cleanserverrules bzw. /cleanclientrules schon probiert

Hallo zusammen, wir haben über die letzten 2 Wochen eine Migration von Exchange 2010 zu Exchange 2016 CU12 gemacht. Die Migration ist auch ohne nennenswerte Probleme durchgelaufen - bis auf folgendes: Bei (bis dato gemeldeten) 5 Postfächern funktionieren eingerichtete Regeln nicht mehr automatisch (Bei den anderen Postfächern vermute ich, das sie a) keine Regeln nutzen oder b) die Regeln so alt sind und "von daher" keine Mails mehr bekommen oder c) es noch nicht gemerkt haben). Die Regeln als solches funktionieren schon noch - solange man sie im Outlook manuell über "Regeln" -> "Regeln jetzt anwenden" startet -- nur eben der Automatismus dies zu tun, wenn eine neue Mail reinkommt NICHT. Folgendes haben wir schon probiert: - Outlook SRS Files gelöscht und Mailprofil neu erstellt - alle Regeln gelöscht und (in Teilen zumindest) neu angelegt. - Regeln wieder gelöscht und via OWA und/oder Powershell neu angelegt. - kein OL gestartet beim Test "via OWA angelegten" Regeln. - Postfach via New-Moverequest in andere Pstfach-DB verschoben - vorgenanntes Wahlweise im Outlook Offline/Cache, wie auch im Onlinemode. ** EDIT vergessen: ** - "outlook.exe /cleanrules" bzw. /cleanserverrules bzw. /cleanclientrules (natürlich nur immer ein Parameter und dann jeweils OL-Neustart) - und danach jeweils Kontrolle mittels "Get-InboxRule" --> keine Regeln für das Postfach vorhanden Egal wie -> die eingerichteten Regeln werden nicht automatisch ausgeführt -- unabhängig der gewünschten Aktionen. Selbst die einfachste Regel "Wenn von EMail-Adr. a@b.c verschiebe in Ordner abc" werden nicht automatisch ausgeführt. Momentaner Workaround ist ein "NewMail()" Event - Macro im Outlook, der dann alle Regeln einmal anstösst. - Problem hier ist natürlich, das Outlook zwingend laufen muss (also auch für Regeln, die sonst Server-basiert starten würde - Die Regeleinstellung "Keine weiteren Regeln anwenden" außer Acht gelassen wird da der Script einfach alle Regeln anstartet, die vorhanden sind. Aktuell habe ich allerdings keinerlei Idee mehr in welche Richtung ich überhaupt suchen könnte oder müsste und hoffe hier den ein oder anderen Tipp zu bekommen. Euch besten Dank im Voraus. Gruß Uwe

Ein einfaches: "Ja, SAN Zertifikate funktionieren für diese Fragestellung wenn der CN auch als SAN eingetragen ist", hätte mir durchaus gereicht. ... auch wenn man schon 20 Jahre in der IT arbeitet, ist jedes Thema irgendwann für jeden mal Neuland (gewesen) - und die Konstellation hatte ich vorher eben auch noch nie. Danke Dir und ein schönes WE Uwe