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

Inzwischen kann ich ein kleines Update hierzu geben: Ich habe mir testweise ein einfaches "Single-Zertifikat" ausstellen lassen mit einem cn="mail.kunde.de" (kein SAN) und das installiert: funktioniert sofort. Das eigenartige ist, das das SAN-Zertifikat ebenfalls einen cn="mail.kunde.de" hatte - allerdings eben auch noch weitere SAN-Einträge (und nicht mail.kunde.de nochmal als SAN-Name) -- dies scheint NorbertFe's Aussage (durchaus) zu untermauern Sicher ist jedenfalls, das der DNS-Name des Systems (vpn.kunde.de) irrelevant hierfür ist - einzig der eingetragene FQDN im SMTP unter "Eigenschaften->Zustellung-> Erweitert" ist entscheidend (sobald ich diese abändere funktioniert auch das "neue" SingleName Zertifikat nicht). Bevor ich jetzt das Original Zertifikat nochmal abändere und mail.kunde.de zusätzlich als SAN Name mit aufnehme... Kann jemand SICHER bestätigen, das SMTP-TLS überhaupt mit SAN Zertifikaten funktioniert? Danke und Gruß Uwe

Bei mir wird die kleine Schrift "gut" angezeigt - werde aber beim nächsten mal drauf achten :-) vSMTP = virtual SMTP = mehrere Instanzen (von mir kreiertes Kunstwort :D ) Hallo NorbertFe, du meinst damit AUCH als SAN-Name? - Also im/als CommonName UND SAN-Name? Danke und Gruß Uwe

Hallo zusammen, ich kämpfe heute schon den ganzen Tag und bin noch nicht wirklich weiter gekommen. Folgende Umgebung (die bis auf _dies_ Problem auch schon seit Jahren so,unverändert läuft): Server 2008R2 mit Exchange 2010 auf Server "mail.kunde.de" Server 2008R2 mit 2 vSMTP Instanzen auf Server "vpn.kunde.de" (AntiSpam GateWay das Mails vom Internet annimmt und dann an den Exchange weiterleitet und die 2. Instanz über die Exchange ins Internet versendet). Auf dem Server "vpn.kunde.de" sollte nun SMTP-TLS aktiviert werden um zu versch. ext. Domains die Kommunikation zu verschlüseln. Wir haben ein offizielles SAN EV Zertifikat: cn = mail.kunde.de san = vpn.kunde.de 4 weitere SAN Namen, die hier aber irrelevant sind Auf beiden vSMTP Instanzen auf dem vpn.kunde.de ist unter Eigenschaften->Zustellung-> Erweitert "mail.kunde.de" als FQDN eingetragen (da er sich auch im HELO so meldet und dies auch dem offizielle MX Record entspricht). Trotzdem weigern sich beide SMTP Instanzen das Zertifikat "anzuerkennen" => "TLS ist ohne Zertifikat nicht verfügbar" und korrespondierender Eintrag im Event-Log: "Für die virtuelle SMTP-Serverinstanz '1' wurde kein verwendbares TLS-Serverzertifikat gefunden. Für diesen virtuellen Server wird TLS deaktiviert" Installiert ist das Zertifikat unter "Computer -> Eigene Zertifikate" (war auch schon im Dienstekonto des SMTP usw.) Nach jeder Änderung natürlich ein IISReset durchgeführt. Frage(n): - Welche Namen werden "wo" (cn / sanName) erwartet? - Funktioniert SMTP-TLS möglicherweise mit SAN Zertifikaten generell nicht? - unterstützt der SMTP Dienst ein "Fallback" auf unverschlüsselt, wenn die Gegenstelle kein TLS unterstützt, oder muss ich für jede "TLS-enabled-RemoteDomain" eine eigene RemoteDomain mit TLS-aktivert erstellen? - gleiche Frage wie vor, jedoch für eingehende Mail Das Zertifikat "als solches" ist OK, das es auf dem Exchange (OWA) und 2 anderen Masch. (https-Webseiten) bereits installiert und aktiviert ist. Vielen Dank schon einmal überhaupt fürs Lesen und einen noch größeren Dank für einen hilfreichen Tip. Gruß Uwe

Na ja - ob Plugin oder ext. Programm a'la ActiveSync wäre ja egal... ich fürchte aber das du Recht haben wirst mit "mangels Masse". Mal schauen, ob evtl. sonst noch jemand ne Idee hat. Nichts desto trotz - Dir schon einmal vielen Dank für Deine Mühen. LG Uwe

Der Rechner soll als völlige "StandAlone" Lösung bestehen bleiben - nur Termine & Kontake sollen mit dem Exchange-Konto synchronisiert werden. Mit Bordmitteln alleine sicher nicht... Wobei der Begriff "bei Exchange Konto abgeholt" so ja auch nicht gewollt ist: Synchronisiert ;) Dann hätte ich aber doch eine PST Datei für die eMails und (zumindest optisch im Outlook) einen 2. Outlook Ordner für Termine etc. (also optisch, als hätte man z.B. einen ArchivOrdner zusätzlich geöffnet) Daher ja auch der urspr. Titel "Outlook als ActiveSync Client" :) Mein Traum ist also ein Plugin für Outlook, das über ActiveSync-Protokoll/Funktionalität mit dem Exchange kommuniziert, und die definierten OutlookItems synchronisiert. VG Uwe

Hallo Günther, vielen Dank für Deine schnelle Antwort - das liest sich jedoch für mich nicht nach der Lösung. Das ich damit ein VPN umgehen kann ist schon klar. Ziel ist es aber nicht ein fernes Outlook irgendwie an den Exchange zu bringen, sondern NUR die beiden genannten Ordner zu synchronisieren. Das Outlook an Standort(B) soll ansonsten schon völlig autark bleiben. Oder habe ich die "Doku" aus deinem Link völlig falsch verstanden? Besten Dank Uwe

Hallo zusammen, der Titel mag etwas merkwürdig klingen.... Folgendes Problem versuche ich zu lösen: Standort (A): Exchange 2007 mit, "nach aussen", funktionierender Active-Sync-Webseite / Service Standort (B): Outlook 2007 "Standalone" mit POP3 Postfach Nun würde ich gerne erreichen, das Standort (B) in der Lage ist Kontakte und Termine mit einem definierten Postfach in Standort (A) zu synchronisieren. Früher gab es an Standort (B) ein "WindowsMobile Handy" mit eingerichtetem Exchange-Active-Sync-Konto und per USB angeschlossenem lokalen Computer/Outlook. Im jeweiligen Sync Profile waren nur Kontakte & Kalender angehakt. Da das Handy defekt ist, sollte das ganze nun möglichst mit einer etwas eleganteren Lösung erreicht werden. Ideal / Wunschvorstellung wäre eine Lösung, das sich Outlook selber dem Exchange gegenüber wie ein Active-Sync-Client-Device verhält!? Versch. Synchronisationslösungen habe ich im Internet bereits gefunden - jedoch haben sie (ohne es selber getestet zu haben) augenscheinlich das "Problem", das sie eine VPN Verbindung zum Exchange benötigen - und das sollte möglichst vermieden werden. Gerne nehme ich natürlich auch andere Vorschläge zur Lösung entgegen. Besten Dank für Eure Hilfe und Tips im Voraus. Uwe

Hallo Lukas, den MSDN Link hatte ich wohl auch schon gelesen und (hoffentlich) auch verstanden. In Kurzform interpretiert: der Programmierer übergiebt im Manifest welche minimalen Rechte seine Anwendung benötigt, um korrekt zu funktionieren. Was aber ist mit Applikationen, die KEIN Manifest mitbringen - wie z.B. auch jegliche Form von "malicious Code" (Viren, Würmer etc.)? Ich denke, das dies eigentlich der Hauptentwicklungsgrund von UAC war!? Ich habe dort jedenfalls nichts rauslesen können, wie sich eine Anwendung verhält, wenn sie kein Manifest mitbringt. Besten dank weiterhin für eure Mühe und Geduld.

Danke schon mal für eure Antworten. Den Bericht hatte ich wohl auch schon gefunden (und auch damit versucht) - das Problem unter Win7 (und vermtl bei VISTA identisch) scheint zu sein, das Windows einen Schreibversuch abfängt und den UAC Dialog bringt, BEVOR die Monitoring Tools es protokollieren können (da es unter XP kein UAC gab, bekamen die Programme dann eben ein AccessDenied zurück - und das "sehen" FileMon und konsorten) Zum Verständnis: Gebe ich einem Ordner oder RegKey Vollzugriffsrechte für "Benutzer" dürfte UAC dort doch nicht mehr greifen!? - oder prüft Windows einfach den Versuch dorthin zu schreiben OHNE Überprüfung ob der User Rechte hätte oder nicht? Besten Dank Uwe

Hallo zusammen. die grundsätzlichen Funktionen der Benutzerkontensteuerung (UAC) sind mir wohl bekannt (und erachte sie auch als sinnvoll). Egal ob gut oder schlecht, es gibt nun einmal lieb gewonnene (alte) Software, auf die ich nicht verzichten möchte - die allerdings jedes mal beim Start den UAC Dialog hochbringt. Wenn möglich möchte ich nicht jedes mal den Dialog bestätigen müssen - geschweige denn diese Programme "als Administrator starten", sondern ihnen nur die zusätzlichen Rechte geben, die sie brauchen um ohne UAC Dialog zu starten (und damit natürlich auch nicht die bekannten Tricks über Aufgabenplanung etc. einsetzen) Bei 1 Programm half es z.B. auf "C:\Program Files\ProgrammName\SubFolder" den "Benutzern" Schreibrechte zu geben, da das Programm dort Dateien ablegen wollte. Nun meine Frage: Kennt jemand eine Möglichkeit herauszufinden WARUM Windows den Dialog bringt? (klar.. Adminrechte erforderlich) - aber herauszufinden was GENAU an dieser Stelle erfordert Adminrechte? Danke im Voraus Uwe