Outlook 2010, Probleme nach Klick auf einen Mailto:Link

Veröffentlicht am 20. September 201217. Juni 2017

Ein Kunde meldet uns das Problem, dass er bestimmte Mails immer als unzustellbar zurück bekommt, obwohl er die Mailadresse mit CopyPaste eingegeben hat, bzw. wie es sich später herausstellt, durch klicken auf einen Mailto:Link in einer Mail.
Hier würde man ja annehmen, dass wirklich nichts falsch gemacht werden kann – ist aber nicht so, es handelt sich letztlich um ein nicht ganz unkompliziertes Problem von Outlook 2007 und 2010 für das es bisher keinen richtigen Hotfix zu geben scheint. (Immerhin ist das Problem selbst bereits lange bekannt und viel diskutiert)

Hier die Fehlermeldung die der User sofort nach dem Senden direkt vom Exchange-Server bekommt:

Ihre Nachricht hat einige oder alle Empfänger nicht erreicht.

Betreff: Test Gesendet am: 20.09.2012 16:51
Folgende(r) Empfänger kann/können nicht erreicht werden: 'friedrich.koelbel@kmf.co.at' am 20.09.2012 16:51 Die Nachricht konnte nicht übermittelt werden, weil das E-Mail-System des Empfängers unbekannt oder ungültig ist. Überprüfen Sie die Adresse,
und wiederholen Sie den Vorgang, oder wenden Sie sich an Ihren
Systemadministrator, um die Verbindung mit dem E-Mail-System des Empfängers zu überprüfen.

<mail.domain.at #5.1.2>

Die Adresse ist also 100% richtig geschrieben, wie kann es dann aber zu dieser Fehlermeldung kommen?

Im Grunde weisen bereits die einfachen Hochkomma (‚) in welche die Mailadresse eingebettet ist daraufhin, ein Blick in die ExchangeServer Verwaltung zeigt uns das eigentliche Problem: In der An:Zeile steht vor der Mailadresse ein „MAILTO:“ das hier nicht hingehört…

Soweit so gut, aber auch jeder andere Versuch des Users, die Adresse neu einzugeben scheitert immer wieder mit dem selben Ergebnis – die Adresse wurde durch den Vorgang in den Adress-Cache von Outlook geschrieben und zieht immer wieder, auch wenn man versucht die Adresse händisch nochmals einzugeben.

Es erreichte uns übrigens eine zweite Fehlermeldung die uns etwas schneller auf die Spur brachte:

Ihre Nachricht hat einige oder alle Empfänger nicht erreicht.
Betreff: WG: Subject
Gesendet am: 20.09.2012 11:51

Folgende(r) Empfänger kann/können nicht erreicht werden:
MAILTO:name@domain.dlt am 20.09.2012 11:51

Die Nachricht konnte nicht übermittelt werden, weil das E-Mail-System des Empfängers
unbekannt oder ungültig ist. Überprüfen Sie die Adresse, und wiederholen Sie den
Vorgang, oder wenden Sie sich an Ihren Systemadministrator, um die Verbindung
mit dem E-Mail-System des Empfängers zu überprüfen.

<mail.domain.at #5.1.2>

Laut verschiedenen Foreneinträgen handelt es sich um ein generelles Problem von Outlook 2007/2010 – wir stellen das Problem hier nach, um eine möglichst einfache Lösung für den User zu finden, der weder am Exchangeserver oder Mailserver-log nachsehen kann, und sich möglicherweise auch keine Hotfixes installieren kann (wie in unserem Fall wegen einer TerminalServer Session ohne Admin-Rechte).
Das angesprochene Hotfix löst im Übrigen auch nicht das Problem im Outlook, sondern es ändern nur die Erstellung von Mailto:Links in allen anderen Office-Programmen, wenn die Links von externen Mails weiterhin im Mailto:Format daherkommen. ändert das aber am Verhalten von Outlook gar nichts…

Um das Problem nachzustellen, genügt es ein beliebiges externes Mail (an sich selbst) weiter zu leiten – dadurch erscheint dann der Mailto:Link – auf ähnliche Weise ist auch das Problem des Users entstanden.

Durch einen Klick auf den Mailto:link erscheint ein neues Mail in dem für einige Zeit die Adresse [mailto:adresse@domain] steht. (das ist eigentlich schon falsch)

Nach einiger Zeit wechselt die Anzeige auf adresse@domain – hier ist doch eigentlich kein Fehler mehr zu erkennen! Und dennoch birgt diese Adresse die auch sofort in den Cache wandert nun zwei Probleme:

Schickt man die Mail nun so ab, erhält man sofort die oben genannte Fehlermeldung:

Gibt man nun die Adresse ein weiteres Mal ein (ein Teil reicht, sie wird aus dem Cache geholt) und macht einen Doppelklick darauf wird einem nichts auffallen – scheint alles OK:

Kein „Mailto“ weit und breit! Trotzdem funktioniert es weiterhin nicht. Was ein sehr geschultes Auge sehen könnte: rechts unten, etwas über dem leeren Balken für Kontakt müsste eigentlich „Kontakt öffne“ stehen (siehe übernächste Screenshot) – dies ist hier der einzige Hinweis, dass die Adresse irgendwie nicht funktioniert…
Im übrigen scheint diese Adresse auch nicht bei den „Vorgeschlagenen Kontakten“ auf – irgendwie scheint sie nur im Cache zu existieren.

Den Cache kann man übrigens auf zwei Arten loswerden: Zum einen kann man den gesamten Cache in den Optionen löschen, oder aber man gibt einen Teil des Namens ein und klickt dann auf das X im Vorschlag.

Interessanterweise hat diese Vorgehensweise bei uns übrigens NICHT funktioniert – nach dem Löschen brachte eine weitere Eingabe der Adresse mit der Hand wieder dasselbe Ergebnis… Wir haben das nicht mehr weiter getestet, für einzelne User wird das hier aber vielleicht schon die Lösung gewesen sein…

Der nächste Ansatz war, auf die (blaue) Mailadresse im mittleren Bereich doppelt zu klicken, was eine neue Mail mit ebendieser Mailadresse aufmacht – ein Doppelklick auf diese Adresse zeigt nun plötzlich rechts unten „Kontakt öffnen“ unser erster Hinweis, dass es nun klappen könnte, und tatsächlich: Die Mail lässt sich nun absenden!

Allerdings birgt diese Methode nochmal einen Fatalen Fehler: Da ich an ein „Nicht Exchange“-Konto geschickt habe, kam die Mail dort verstümmelt ohne Umlaute an, eine testweise eingebettete Grafik wurde zu einem Anhang namens Winmail.dat (!)

Und hier die endgültige Lösung des Problems:

Durch den Klick auf den Mailto:link wurde die Adresse mit einem falschen E-Mail-Typ gespeichert, den es nun zu ändern gilt:

In die E-Mail-Eigenschaften kommen Sie entweder, indem sie über die Mailadresse fahren und dort mit der Maus verweilen oder wieder den Doppelklick machen und dann im der grafischen Menü das ein Blatt darstellt (Weitere Optionen für die Interaktion mit dieser Person) klicken und dann „Outlook Eigenschaften“ auswählen.

Wenn der falsche E-Mail-Typ eingetragen war, dann kommt hier sofort folgendes Fenster, ansonsten kommt bereits die Ansicht des Kontaktes (analog wie oben gezeigt, ob „Kontakt bearbeiten“ angezeigt wird, oder nicht)

Hier sieht man nun, dass der E-Mail-Typ falsch ist, mit einem Klick auf „Internettyp“ wechselt der Typ auch sofort auf ein nicht mehr veränderbares „SMTP“ – diesen Effekt hatte auch schon die oben genannte Methode, aus dem einen Mail ein zweites aufzumachen – hier aber haben wir nun die Möglichkeiten auch das „Internetformat“ von „Im Outlook-Rich-Text-Format senden“ auf „Outlook wählt das optimale Sendeformat“ zu wechseln, denn genau dieser Punkt war der Grund, dass die Mail dann verstümmelt und mit einem winmail.dat beim Empfänger angekommen ist.

Ein „OK“ an dieser Stelle aktualisiert auch sofort den Cache, danach kann man ganz normal an diese Adresse senden…

Kommt bei Ihnen übrigens bei „Outlook Eigenschaften“ statt dem Eigenschaftsfenster ein Kontaktfenster und sie wollen das Internetformat trotzdem ändern, dann wiederholen Sie den Vorgang hier in diesem Dialog an der Zeile E-Mail – nochmals mit der Maus über der Adresse verweilen und nochmals wie oben auf das Blatt und „Outlook Eigenschaften“ auswählen – danach kommt dann endlich wirklich der oben gezeigte Eigenschaftsdialog.

Exchange Mails kommen verzögert an

Veröffentlicht am 13. September 201217. Juni 2017

Problem:

Plötzlich kommt die Meldung von Usern eines Exchange Servers 2010, dass Mails „manchmal“ Stunden zu spät zugestellt werden – es findet sich kein Hinweis auf den Grund, bis auf den einen dass im Header einer solchen zu spät zugestellten Mail gezeigt werden kann, dass dies Nachricht mehr als 12h auf unserem externen Mailserver mailex01 „liegen geblieben“ ist – ein Blick in unsere Mailqueue zeigt aber keine weiteren Mails die zugestellt werden sollen, Testmails gehen auch sofort durch…

Erst nach einem Tag zeigt sich dann folgendes Bild in der Queue unseres Mailservers Mailex01:

mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- A4CC5A414D 19554 Thu Sep 13 22:03:46 mailrobot@xing.com (host mail.xxxxxxx.at[80.123.180.174]
 said: 452 4.3.1 Insufficient system resources (in reply to MAIL FROM command)) harald.xxxxx@xxxxxxx.at

Lösung:

Der Grund ist, dass am ExchangeServer auf C: nur noch 5GB frei waren und das laut Einstellung für Exchange zuwenig ist um noch Mails zu zustellen (!!!)
Einige Mails sind dann immer wieder durchgekommen, weil sich die Größe des freien Speicherplatzes am Server durch verschiedene Prozesse wie Sicherung und Temp-Files immer wieder geringfügig geändert hatte…

Lösungen findet man hier, hier und hier.

Unsere Lösung beim Kunden: Auf D:\ sind über 200GB frei, daher wird die „Queue“ einfach hierhin verlegt…

Datei: „C:\Program Files\Microsoft\Exchange Server\V14\Bin\EdgeTransport.exe.config“ als Administrator editieren, „QueueDatabasePath“ und „QueueDatabaseLoggingPath“ von einem Pfad auf C:\ auf einen Pfad auf D:\ ändern.

ändern auf:

Danach muss nur noch der Exchange Transportdienst durchgestartet werden.

Tags: „Exchange 2007“, „Exchange 2010“, „Exchange nimmt keine Mails mehr an“, „452 4.3.1 Insufficient system resources“

Access Meldung „Datei nicht gefunden“

Veröffentlicht am 4. September 20129. Juni 2017

Drei verschiedene Probleme haben mich bei Access-Programmen in den letzten Jahren immer wieder in unangenehme Situationen geführt:

„Datei nicht gefunden“

Aus heiterem Himmel kommt beim Start einer Access-Datei die Meldung „Datei nicht gefunden“ – dies passiert ab und zu während des Programmierens.

In meinem Fall war durch Programmänderung eine Backend-Datei (das Programm) auf 24MB angewachsen, obwohl die Datei eigentlich nur ca. 11MB haben sollte – ein Standardvorgang (Extras, Datenbank-Dienstprogramme, Datenbank komprimieren und reparieren) – dies hat wohl an die 10 Mal an einem Tag funktioniert, dann kam aber plötzlich die Meldung „Datei nicht gefunden“ – dabei kann anscheinend durch nichts herausgefunden werden, um welche Datei es sich handelt, bzw. um welchen Programmteil, Modul, Formular oder Tabellenverknüpfung, denn die Acess-Datei selbst startet ja und es sind eigentlich keine weiteren Dateinen notwendig – grundsätzlich handelt es sich wahrscheinlich um eine Verknüpfung zu einer DLL – einem Verweiß wie es in Access-Sprache heißt – aber es kann nicht herausgefunden werden welche das sein sollt und man kann auch nicht mehr mit der Datei weiter arbeiten – Die Datei ist somit eigentlich unbrauchbar.

„Absturz kurz nach dem Öffnen“ (2003)

Ähnliche Situation wie oben beschrieben, allerdings kommt keine Fehlermeldung aber Access stürzt kurz nach dem Aufruf ab – dies betrifft dann nur diese eine Datei, andere Dateien lassen sich ganz normal bearbeiten.

„Access bleibt hängen“ (2010)

Beim Klick auf ein bestimmtes Formular bleibt Access einfach stehen, evtl. steht in der Taskleiste „Berechnung läuft“, aber die Daten erscheinen nicht. Klickt man dann wo anders hin, kommt ein Dialog dass Access nicht mehr reagiert. (also eigentlich ähnlich wie „Absturz nach dem Öffnen“ aber doch etwas anderes Verhalten…) – wichitg vielleicht noch, dass es sich nich um eine Riesen Datenmenge handelt, sondern ein Formular welches früher innerhalb einer Sekunde offen und bearbeitbar war.

„Access APPCRASH“ (2010)

Beim Versuch eine Access-Datenbank zu öffnen kommt eine Fehlermeldung „Microsoft Access funktioniert nicht mehr“ und in den Details der Hinweise „APPCRASH“ (dazu gibt es auch einen eigenen Artikel)

Gleichzeitig findet man im Taskmanager (Ereignisanzeige, Ereignisprotokolle anzeigen)

Name der fehlerhaften Anwendung: MSACCESS.EXE, Version: 14.0.6024.1000, Zeitstempel: 0x4d83e4fc
Name des fehlerhaften Moduls: VBE7.DLL, Version: 7.0.16.19, Zeitstempel: 0x4d430aec
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00023081
ID des fehlerhaften Prozesses: 0x22f0
Startzeit der fehlerhaften Anwendung: 0x01cf4e6bb3f096ac
Pfad der fehlerhaften Anwendung: C:Program Files (x86)Microsoft OfficeOffice14MSACCESS.EXE
Pfad des fehlerhaften Moduls: C:PROGRA~2COMMON~1MICROS~1VBAVBA7VBE7.DLL
Berichtskennung: f30a7ccc-ba5e-11e3-9e54-78e3b51c15e2

Lösung:

Eine Lösung die ich in den ersten drei Fällen früher schon angewendet habe, wäre eine neue leere Datenbank zu beginnen und dort alle Daten/Module/… aus der korrupten Datenbank zu importieren.

Diese Lösung ist aber ein wenig unbefriedigend, weil alle Einstellungen/Verweise/Optionen auch wieder nachgeführt werden müssen.

Ich habe aber in der Zwischenzeit eine weitaus einfacher Lösung gefunden: Access mit dem Parameter /decompile starten und die betreffende Datei einfach nur öffnen!

Access 2003
„C:ProgrammeMicrosoft OfficeOFFICE11MSACCESS.EXE“ /decompile
danach einfach über „Datei öffnen“ die korrupte Datei öffnen
oder:
„C:ProgrammeMicrosoft OfficeOFFICE11MSACCESS.EXE“ /decompile Pfad/und/Name/der/datei.mdb

Access 2010 (Access 2007)
„C:Program Files (x86)Microsoft OfficeOffice14MSACCESS.EXE“ /decompile
danach einfach über „Datei öffnen“ die korrupte Datei öffnen
oder:
„C:Program Files (x86)Microsoft OfficeOffice14MSACCESS.EXE“ /decompile Pfad/und/Name/der/datei.mdb

Diese einfache Lösung hat in allen Fällen sofort zum Erfolg geführt!

Tags: „Microsoft Access“, „Access 2003“, „Access 2007“, „Access 2010“, „Access APPCRASH“, „Microsoft Access funktioniert nicht mehr“

User bekommen nur temporäres Benutzerprofil

Veröffentlicht am 14. Mai 201217. Juni 2017

Nach einem Serverabsturz (Windows 2008 R2 Terminal Server, Roaming Profile) können sich einzelne User nicht mehr normal einloggen. Sie bekommen folgende Meldung:

Das lokale Benutzerprofil wurde nicht gefunden. Sie werden mit einem temporären Benutzerprofil angemeldet. Änderungen, die Sie am Benutzerprofil vornehmen, gehen bei der Abmeldung verloren.

Korrespondierend findet man in der Ereignisanzeige auch den Eintrag:

Protokollname: Application
Quelle:        Microsoft-Windows-User Profiles Service
Ereignis-ID:   1511
Aufgabenkategorie:Keine
Ebene:         Fehler
Beschreibung: Das lokale Benutzerprofil wurde nicht gefunden. Sie werden mit einem temporären Benutzerprofil angemeldet. Änderungen, die Sie am Benutzerprofil vornehmen, gehen bei der Abmeldung verloren.

Die User können sich zwar einloggen, erhalten dann aber entsprechend ein leeres neues Profil, welches tatsächlich auch nicht auf deen Server zurückgespeichert wird.
Weiters wird auch kein Unterverzeichnis C:\users\<username> erstellt.

Mehrfaches ein- und ausloggen hilft genausowenig wie das durchstarten des Servers.

Variation: Ebenfalls nach einem Absturz auf einem Windows 2008 R2 Application Server kommt beim Versuch sich als Domainadminstator mit lokalem Profil einzuloggen die Meldung:

C:\Windows\system32\config\systemprofile\Desktop bezieht sich auf einen Pfad, der nicht verfügbar ist.

Mit diesem Desktop kann man danach nicht sinnvoll arbeiten – jeder Versuch den Explorer zu öffnen oder ähnliches bringt wieder die selbe Meldung.
Diese Meldung sieht man allerdings nur am Bildschirm. In der Ereignisanzeige steht zur selben Zeil etwas ganz anderes:

Protokollname: Application
Quelle:        Microsoft-Windows-User Profiles Service
Ereignis-ID:   1505
Aufgabenkategorie:Keine
Ebene:         Fehler
Beschreibung: Das Profil konnte nicht erfolgreich geladen werden, aber Sie wurden mit dem standardmäßigen Profil für das System angemeldet.
Details – Zugriff verweigert

Lösung: (für beide Fälle)

Ausführen: regedit (als Administrator)

zu folgendem Pfad navigieren: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
alle Einträge mit S-xxxx.bak löschen.

(alle User, die eine .bak-Zeile haben sind betroffen

Danach können sich die User sofort wieder normal einloggen – die Profile werden wieder vom Server geholt.

Siehe auch: http://support.microsoft.com/kb/947242/de

Tags: Terminalserver, Citrix, Profil, Roaming Profile, „Der Pfad ist nicht verfügbar Desktop“

Microsoft ActiveSync oder kurz ActiveSync

Veröffentlicht am 7. April 20127. April 2022

Ist ein Protokoll von Microsoft, das für die Kommunikation zwischen Exchange und mobilen Endgeräten entwickelt wurde.

Es synchronisiert eMails, Kontakte, Kalendereinträge, Aufgaben und Notizen von einem Nachrichten-Server mit einem Client. Darüber hinaus können auch einfache Device-Policies und Geräteeigenschaften gesteuert werden.

Verbesserte Such-Möglichkeiten und DirectPush gehören ebenso zum Funktionsumfang.

Ein nicht unerhebliches Feature ist die Möglichkeit, Geräte via Remote-Wipe zu löschen. Das kann eventuell bei Verlust oder Diebstahl notwendig sein.

Excel VBA TextExport: Problme beim Datumsformat

Veröffentlicht am 16. Januar 201216. Januar 2012

Problem: Eine Excel Tabelle in der unter anderem auch Spalten mit Datumsfeldern vorkommen soll in ein Texfile exportiert werden – im Textfile wird das Datum aber in einem falschen Format angezeigt (Englisch)

Datum in Excel: (Datumsformat: deutsch, standard)

Nach dem Export in eine Textdatei über das Menü, oder auch über folgende VBA-Funktion erhalten wir in der Textdate ein falsches Datumsformat

ActiveWorkbook.SaveAs Filename:=strSaveAsText, FileFormat:=xlUnicodeText, CreateBackup:=False

8/31/2011 LV 1000 9/04/2011 4 EUR INTERN
8/31/2011 LV 1000 9/06/2011 4 EUR INTERN

Dieses Datumsformat wird dann aber von dem Programm welches die Daten wieder importiert nicht verstanden – daher wäre eine deutsche Formatierung des Datums beim speichern erwünscht.

Lösung: über den Parameter „Locale=true“ wird erreicht, dass Excel die Datumseinstellung des aktuellen Desktops (Systemsteuerung) verwendet

ActiveWorkbook.SaveAs Filename:=strSaveAsText, FileFormat:=xlUnicodeText, CreateBackup:=False, Local:=True

31.08.2011 LV 1000 04.09.2011 4 EUR INTERN
31.08.2011 LV 1000 06.09.2011 4 EUR INTERN

Anmerkung: Grundsätzlich ist diese Lösung nicht ganz zufriedenstellend, denn wenn der User beim Exportieren eine andere Systemeinstellung für die Sprache wählt, wird sich das Ausgabeformat des Textes wieder ändern und es wird wohl beim Import in das Folgeprogramm zu einem Fehler kommen. Daher wäre es wünschenswert, wenn nicht nur „Local=True“ gesetzt werden kann, sondern gleich ein fixes Format für den Output gewählt werden kann.
Es gibt tatsächlich auch den Paramter „TextCodepage“ über den die Ausgabesprache fix festgelegt werden könnte, dieser Parameter wird jedoch im speziellen in Excel ignoriert.
Will man dieses Problem professionell lösen, so müsste man den Export mit einem weiteren VBA-Programm entweder mittels format() beeinflussen und z.B. Zeilen- und Spaltenweise exportieren, oder evtl. das ganze Workbook vor dem Export per VBA im richtigen Format in eine neue Seite einfügen und dabei das Datum in einen Text umwandeln – dach wird der Export auch ganz ohne Parameter immer richtig gelingen!

Betrifft: Excel 2000, Excel 2003, Excel 2007, Excel 2010

Access Recordsource nach 256 Zeichen abgeschnitten

Veröffentlicht am 9. Januar 20129. Januar 2012

Betrifft: Microsoft Access XP, 2000, 2003 (noch nicht getestet mit 2007, 2010)

Problem: Sie wollen die Recordsource einer Form als String auslesen, diese wird jedoch nach 256 Zeichen abgeschnitten.

strSQL = Me.Recordsource
debug.print Len(strSQL)
256

Der Grund für das Problem könnte folgender sein: Sie haben die Datenquelle der Form mit Me.Recordset oder Me.RecodesetClone gesetzt – dabei wird anscheinend der Recordset-String nicht sauber gesetzt.

Set rs = CurrentDb.OpenRecordset(strSQLStart & strSQL & strGroup & strOrder, dbOpenDynaset)
Set Me.Recordset = rs

Obwohl diese Abfrage an sich auch bei langen Strings perfekt funktioniert wird eben nur die Eigenschaft Me.Recordsource nicht richtig gesetzt.
Soll später etwa in einem anderen Formular oder Bericht aber genau dieser String ausgelesen werden kommt es zu einem Problem.

Als Lösung können können Sie folgende Änderung vornehmen:

Me.Recordsource = strSQLStart & strSQL & strGroup & strOrder

Danach kann der Recordset auch wieder in größerer Länge als 256 Zeichen ausgelesen werden.
Sofern es den restlichen Programmverlauf nicht stört, kann man dann auf „set rs“ komplett verzichten!

Phishing, SCAM – „Ihre PayLife Karte ist aus Sicherheitsgründen begrenzt.“

Veröffentlicht am 21. September 201117. Juni 2017

Wieder mal eine Anfrage die sich als Phishing bzw. als SCAM entpuppt – diesmal ganz mit Österreich-Bezug und schon relativ wenigen Rechtschreib- und Grammatikfehlern…

Folgende Meldung erreicht uns und unsere Kunden wieder seit einigen Tagen:

 Betreff: Wichtig: Ihr PayLife Karte ist aus Sicherheitsgründen begrenzt.  Von: PayLife Bank GmbH Entsperren Karte aufsperren@paylife.kreditkarte.at    Sehr geehrte Mitglieder PayLife Bank,  Ihre PayLife Karte ist aus Sicherheitsgründen begrenzt.  Wir glauben, dass jemand sich mit Ihrer Karte für betrügerische Nutzung.    Um Beschränkung zu entfernen und zu sichern Ihre Karte laden Sie   bitte das beigefügte Formular aus und folgen Sie den Schritten.

 Wenn Sie nicht abgeschlossen haben alle Schritte Ihrer Karte endgültig gesperrt werden.   Wir bedauern die Unannehmlichkeiten,   PayLife Bank GmbH  Postfach 574, 1011 Wien

Die Schreibweise und Rechtschreibung sollte den Leser an sich schon etwas fraglich stimmen – kann eine Bank so schlecht schreiben? Natürlich nicht – es handelt sich hier um einen dreisten Phishingversuch!
Allerdings gibt es trotzdem immer wieder User die darauf hereinfallen und genau die Angst bekommen, die das Mail erzeugen soll und tatsächlich versuchen ihre Karte zu entsperren.

Danach kommt dann als Oberdreistigkeit auch noch folgendes HTML-Formular:

Im Screenshot ist schon zu sehen, dass in unserem Beispiel das Mailprogramm bereits vor einem Phishingversuch warnt – was in diesem Fall absolut ernst zu nehmen ist. Die Eingabe der Codes und Passwörter öffnet dem Angreifer natürlich erst recht die Tür – trotzdem gibt es anscheinend immer wieder Fälle in denen User einfach Ihre Daten eingeben un diese einfach absenden.

Neben „Phishing“ gibt es eine weitere verwandte Bezeichnung für diese Mails: Sie verunsichern die meisten Empfänger und werden daher „SCAM“ (eine Kombination aus „scare“ (sich fürchten) und „SPAM“) benannt.

Der vermeintliche Absender weiß höchstwahrscheinlich gar nichts von diesem Mail und würde ein solche Mail auch nie versenden – loggen Sie sich in einem solchen Fall immer ganz ohne Link auf der Homepage des „echten“ Betreibers ein und schauen Sie, ob dort auch wirklich eine gleichlautende Meldung steht. Beim Login ist zusätzlich darauf zu achten, dass in der Browser-URL HTTPS zu finden ist und auch das Schlüssel-Symbol für eine gesicherte Verbindung aufscheint.

Bitte ignorieren Sie solche Anfragen genauso wie sie auch jede Viagra-SPAM-Mail ignorieren würden – leider rutschen solche Mails am Beginn durch die meisten Spamfilter, weil sie nicht in so großen Massen auftreten wie Spams und auch nicht eindeutig als SPAM zu klassifizieren sind.
Im besten Fall leiten Sie solche Mails an die „Abuse“-Adresse der jeweiligen Bank weiter – also z.B. abuse@paylife.at – das zeigt den zuständigen Administratoren möglicherweise dass es wieder eine neue noch nicht bekannte Welle von Phishing-Versuchen bzw. SCAM gibt, und diese können auf ihrer Homepage reagieren…

Citrix Fehlermeldung Lizenzabruffehler (500) nach Neuinstallation

Veröffentlicht am 2. September 201117. Juni 2017

Nach der Neuinstallation eines Citrix-Servers 4.5 unter Server 2003 kommt es beim Versuch sich als User einzuloggen zu folgender Fehlermeldung:

Lizenzabruffehler (500) Es konnte keine Lizenz vom Server (xxx) abgerufen werden

Weiters kommt in einer zweiten Messagebox die Meldung:

Anmeldung
Sie müssen über die Zugriffsberechtigung für Terminalserverbenutzer auf dem Computer
verfügen, um sich remote anmelden zu können. Standardmäßig verfügen Mitglieder der
Gruppe „Remotedesktopbenutzer" über diese Berechtigung.
Wenn Sie kein Mitglied der Gruppe „Remotedesktopbenutzer" oder einer anderen Gruppe,
die über diese Berechtigung verfügt, sind bzw. wenn die Gruppe „Remotedesktopbenutzer"
nicht über diese Berechtigung verfügt, muss Ihnen die entsprechende Berechtigung
manuell zugewiesen werden.

Allerdings wurde zuvor schon sichergestellt, dass alle Benutzer der Domain der Gruppe „Remotedesktopbenutzer“ angehören und auch die Administratoren der Domain entsprechend in diese Gruppe eingetragen.

Die selbe Frage ohne konkrete Lösungen findet man auch etwa hier:

http://www.circleofexpertise.com/forum/12-xenapp–citrix-presentation-server/43706-lizenzabruffehler-500.html
http://www.circleofexpertise.com/forum/12-xenapp–citrix-presentation-server/42556-lizenzabruffehler-500-nach-evaluierungslizenz.html

Lösung:

Es liegt möglicherweise an der Serveredition. In unserem Fall wurde bei der Installation irrtümlich die „Enterprise Edition“ gewählt, die aber nicht lizenziert ist.
In den in den Links beschriebenen Fällen ist das selbe passiert, weil z.B. zuzvor die Evaluierungslizenz und somit ebenfalls „Enterprise Edition“ eingestellt war – nach der Umstellung auf die Normallizenz „Advanced Edition“ wurde nich auf diese Version umgestellt. (Wie auch – die Fehlermeldung ist diesbezüglich üpberhaupt nicht eindeutig…)

Umstellung der Edition: Betroffenen Server in der Delivery Console auswählen, rechte Maus, „alle Aufgaben“, „Serveredition einstellen“

hier wird dann die ensprechende Version gewählt und der Server rebootet. Danach funktioniert das Login ohne die oben genannten Fehlermeldungen.

Tags: „citrix edition ändern“

Drucker einer fremden Domain verbinden

Veröffentlicht am 17. August 201117. Juni 2017

Frage:

Ich haben einen Rechner der in einem Netzwerk mit einer Domain steht, selbst aber nicht in dieser Domain eingeloggt ist. Verbinde ich nun Laufwerke oder Drucker aus dieser Domain so funktioniert das zwar super, allerdings werden die Passwörter von Zeit zu Zeit anscheinend „vergessen“ – bei den Druckern wirkt sich das so aus, dass diese bei einem Rechnerneustart plötzlich „offline“ sind und ich keinen Weg finde sie wieder auf „online“ zu stellen (Windows 7) – weiters gibt es keinen Dialog, der User und Passwort abfragen würde.

Antwort:

Beim „vergessen“ der Passwörter kann es auch sein dass sich die Passwörter geändert hätten, aber wir haben auch schon beobachtet, dass es nach ein paar Logins einfach nicht mehr geht und der User nicht erneut nach LoginDaten gefragt wird.
Es gibt aber ein einfaches Programm als Windows Bordmittel mit dem man die User und Passwörter zu entfernten Rechnern verwalten kann – dabei ist nur der Rechnername und das Passwort notwendig, der Drucker oder auch die Dateifreigabe verwendet diese Daten dann selbständig.
Aufruf unter „Ausführen“ oder in der Commandline:

rundll32.exe keymgr.dll,KRShowKeyMgr

Der Dialog ist selbserklärend und hier können auch alte nicht mehr benötigte User/Passwort-Kombis rausgeworfen werden.

Unter Windows XP und Server 2003 können nur normale User verwaltet werden, ab Vista, Windows 7, Server 2008 können auch User für Internetseiten an dieser Stelle verwaltet werden und zusätzlich können die Daten für den Transfer auf einen weiteren Rechner auch gesichert und wieder hergestellt werden!

Weitere Tags: „Netzlaufwerk verbinden“, „remove saved Passwords“, „gespeicherte Passwörter entfernen“, „gespeicherte Passwörter löschen“