Telegram – Importierte Kontakte löschen

Problem

Telegram (in der Android-Version) Importiert standardmäßig erstmal alle Kontakte, die es im System findet. Also Telefonbuch, SIM-Kontakte, usw.
Das mag prinzipiell auch recht hilfreich sein, schließlich möchte man ja i.d.R. über einen Messenger auch tatsächlich kommunizieren.

Hat man aber nun, z.B. aus einem Notfall heraus beispielsweise kurzzeitig die SIM-Karte eines Bekannten im eigenen Handy benutzt, braucht man die Kontakte davon normalerweise nicht in seinem Telegram-Account.

Diejenigen, welche Telegram bereits nutzen kann man auch Problemlos in der App löschen (Kontakte -> Kontakt Löschen)
Über Leute, welche beim Import der Kontakte allerdings noch keinen Telegram-Account hatten und sich später einen zulegen, wird man dann jedes mal freundlich informiert.

Lösung

Möchte man diese allerdings schon im Vorhinein, also bevor man überhaupt dazu benachrichtigt wird, wieder aus seinen Kontakten löschen funktioniert das wie folgt:

  1. Telegram (Android-App) Starten
  2. Über das Menü die Einstellungen der App öffnen
  3. Ganz runter scrollen und die Versionsinfo (z.B. “Telegram für Android v4.8.11 (1318) arm64-v8a”) antippen und gedrückt halten
  4. Nach kurzer zeit erscheint ein Shrug-Emoji (“¯\_(ツ)_/¯”) -> loslassen und das ganze nochmal
  5. Diesmal öffnet sich das Debug-Menü
  6. Hier kann man dann “Importierte Kontakte Zurücksetzen

Bei unserem Test wurden dadurch keine Kontakte beeinflusst welche sich tatsächlich aktuell im Telefonbuch und Co. befinden bzw. mit denen Chats aktiv sind.

GFI-Archiver Office 365 – Ausführung der automatischen Erkennung fehlgeschlagen

Problem

Man möchte mit dem GFI Archiver den Office 365 Mailverkehr des Unternehmens archivieren, hat dazu die GFI Anleitung befolgt und ist bei Schritt 5 (dieser hier, je nach dem an welcher stelle man ist gibt es scheinbar unterschiedliche 5. Schritte) angekommen.

Man konfiguriert also brav die Verbindung über EWS mit den passenden Zugangsdaten und dem Ordner-Standardwert. Nach dem Klick auf weiter, begrüßt einen die folgende Fehlermeldung:

Fehlgeschlagen während: Verbindung wird getestet
Details: Verbindungsprüfung konnte nicht durchgeführt werden. Details: Ausführung der automatischen Erkennung fehlgeschlagen 

Lösung

Die fehlermeldung ist geringfügig irreführend, denn die Automatische Erkennung hat man ja gar nicht konfiguriert.

Für die EWS-Verbindung ist allerdings der Ordner Entscheidend. Sofern das Postfach für die Sprache „Deutsch“ konfiguriert wurde (z.B. beim ersten Aufruf des OWA) lautet der korrekte Ordnername allerdings Posteingang und nicht mehr Inbox nachdem man diesen also korrigiert hat, funktioniert die Einrichtung wie erhofft.

Windows 10 Store installiert keine Apps mehr (Store-Seite wird neu geladen)

Problem:

Eine App soll über den Microsoft Store heruntergeladen und installiert werden.
Nach Betätigung der „Herunterladen“-Schaltfläche sieht man für einen kurzen Augenblick den Status („In Arbeit…“) aber direkt darauf wird die Übersichtsseite der App neu geladen/aktualisiert und man landet wieder beim Download-Button.

Lösung:

In Unserem Fall half es, das bereits im Store angemeldete Konto einmal dort abzumelden (Oben rechts über das Profil-Icon -> das Konto anklicken -> Abmelden).
Bei einem darauffolgenden erneuten Downloadversuch wird dann wieder nach einem Konto gefragt, dieses einfach wieder Anmelden und schon startet der Download.

DHCP(-Relay) vergibt keine IP an einige Clients

Problem:

Einige Clients (in unserem Fall ein WLAN-AccessPoint von Ubiquiti und ein D-Link Printserver) erhalten keine IP Adresse vom DHCP-Server (Windows Server 2012 R2) hinter einem DHCP-Relay-Agent (Windows Server 2008 R2)
Auf dem DHCP lässt sich kein Fehler finden (Eventlog, DHCP-Log, …)
Ein Paketsniffer (in diesem Fall Wireshark) zeigt jede menge „DHCP Discover“-Pakete, allerdings kein darauf folgendes Offer.

Nach Aktivierung des erweiterten loggings auf dem DHCP-Relay (teil von Routing und RAS) lässt sich im IPBOOTP.LOG (C:\Windows\tracing\IPBOOTP.LOG) folgendes finden:

dropping REQUEST with secs-since-boot 0 on interface XX (192.168.X.X)

Laut Technet sollte das auch im Eventlog auftauchen. (Tat es in unserem fall leider nicht.)

Lösung:

Nach erneuter Betrachtung der Discover-Pakete fällt auf: Der „Seconds elapsed“-Wert steht bei sämtlichen betroffenen Geräten auf 0 

Der DHCP-Relay-Agent verwirft in der Standardeinstellung sämtliche Pakete mit einem „secs-since-boot“-Wert unter 4 Sekunden. Damit auch die hier betroffenen Pakete weitergeleitet werden muss auf dem DHCP-Relay-Interface lediglich der „Neustart-Schwellenwert“ angepasst werden:

  1. Routing und RAS MMC öffnen
  2. IPv4 -> DHCP-Relay-Agent
  3. Eigenschaften der Schnittstelle
  4. „Neustart-Schwellenwert (Sekunden)“ auf 0 herabsetzen

Exchange 2016 OWA/ECP leere Seite nach Login

Problem:

Bei einer On-Premise Exchange Umgebung funktionieren „plötzlich“ Outlook und OWA nicht mehr. OWA und auch die ECP-Site zeigen noch den Login, danach bleibt die Seite allerdings leer.

Im System-Eventlog gibt es massenweise folgendes Event: (Source: HttpEvent; Event-ID: 15021)

Bei der Verwendung der SSL-Konfiguration für den Endpunkt 0.0.0.0:444 ist ein Fehler aufgetreten. Der Fehlerstatuscode ist in den zurückgegebenen Daten enthalten.

Lösung:

Ursache ist eine fehlende Zuordnung des SSL-Zertifikats für die Backend-Site im IIS.

Dort das SSL-Zertifikat wieder bei der korrekten Bindung auswählen, ggfs. den IIS neustarten und schon sollte der Zugriff wieder klappen:

  1. IIS Manager öffnen
  2. Sites -> Exchange Back End
  3. Im Aktionsbereich auf Bindungen
  4. Die https Bindung *:444 Bearbeiten
  5. das SSL-Zertifikat auswählen
  6. ggfs. iisreset

VMware vSphere „Der Vorgang ist im aktuellen Zustand nicht zulässig“

Problem:

Unter VMware lässt sich *auf einmal* kein Snapshot einer Maschine mehr erstellen oder löschen. Das Betrifft selbstverständlich auch Snapshot-basierte Backuplösungen.

Auch eine Migration der Maschine auf einen anderen Host oder Datastore ist nicht mehr möglich.

Es wird die Meldung „Der Vorgang ist im aktuellen Zustand nicht zulässig.“ („The operation is not allowed in the current state.“) angezeigt und auf dem zugehörigen ESX-Host findet man im hostd.log folgenden Eintrag:

error 'Vmsvc.vm:/vmfs/volumes/DATASTORE/VMNAME/VMNAME.vmx'] Invalid transition requested (VM_STATE_ON_SHUTTING_DOWN -> VM_STATE_CREATE_SCREENSHOT): Invalid state

Lösung:

Das Problem lässt sich in der Regel durch einen Neustart der Management-Agents auf dem jeweiligen ESX-Host beheben.

Dazu zunächst SSH auf dem ESX aktivieren (vSphere Client am Host anmelden -> Konfiguration -> Sicherheitsprofil)
und sicherstellen, dass die VMs nicht mit dem Host Starten/Herunterfahren (vSphere Client am Host anmelden -> Konfiguration -> VM starten/herunterfahren -> Virtuelle Maschinen mit dem System starten und beenden auf Deaktiviert stellen)

Dann per SSH auf den Host verbinden und die Management-Agents neustarten:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

Ressourcenpostfach Kalenderbuchungen automatisch akzeptieren um Konflikte zu vermeiden

Problem:

Ein Ressourcenpostfach (Gerätepostfach) soll Kalenderbuchungen automatisch akzeptieren. In der Standardeinstellung sind Konflikte bei der Buchung möglich.

Lösung:

Standardmäßig werden bei Gerätepostfächern Kalenderbuchungen zwar als „Mit Vorbehalt“ im Kalender eingetragen, allerdings nicht automatisch bestätigt. Somit sind auch doppelte Buchungen möglich.

Diese Einstellung lässt sich relativ schnell via Exchange-Management-Shell ändern:

Set-CalendarProcessing -Identity "POSTFACH" -AutomateProcessing AutoAccept