Powering off an unresponsive virtual machine on an ESXi host

If powering off the virtual machine from vSphere Client or Host Client will not work, you can use one of the command line methods below.
 

Determining the virtual machine’s location

  • Determine the host on which the virtual machine is running.
  • This information is available in the virtual machine’s Summary tab when viewed in vCenter web client

Using the CLI to shutdown the unresponsive virtual machine

There are several methods to power off the non-responsive virtual machine using command line as the following:

Its recommended to follow the sections and steps in this article in order.
 


Using vim-cmd

  1. Log in as root to the ESXi using SSH.
  2. Get a list of all registered virtual machines, identified by their VMID and Display Name by running this command:vim-cmd vmsvc/getallvms

Example output:

  1. Take note of the impacted virtual machine ID VMID
  2. Get the current state of a virtual machine by running this command:vim-cmd vmsvc/power.getstate VMID

Example output:

  1. Check if there hanging task on the impacted virtual machine that prevent the machine from powering on by running this command:vim-cmd vmsvc/get.tasklist VMID

Example output:

(ManagedObjectReference) [
'vim.Task:haTask-2-vim.VirtualMachine.createSnapshot-1234567',
'vim.Task:haTask-2-vim.VirtualMachine.consolidateDisks-12345678'
]
  1. Run the vim-cmd vimsvc/task_info task_id command to see the task in more detail.

For example using the data from step 5:

vim-cmd vimsvc/task_info haTask-2-vim.VirtualMachine.createSnapshot-1234567

vim.TaskInfo) {
dynamicType = <unset>,
key = "haTask-2-vim.VirtualMachine.createSnapshot-1234567",
task = 'vim.Task:haTask-2-vim.VirtualMachine.createSnapshot-1234567',
description = (vmodl.LocalizableMessage) null,
name = "vim.VirtualMachine.createSnapshot",
descriptionId = "VirtualMachine.createSnapshot",
entity = 'vim.VirtualMachine:2',
entityName = "VMware vCenter Server Appliance5-1",
state = "running",
cancelled = false,
cancelable = false,
error = (vmodl.MethodFault) null,
result = <unset>,
progress = 50,
reason = (vim.TaskReasonUser) {
dynamicType = <unset>,
userName = "********",
},
queueTime = "2014-11-09T17:49:01.171933Z",
startTime = "2014-11-09T17:49:01.175521Z",
completeTime = <unset>,
eventChainId = 1234567,
changeTag = <unset>,
parentTaskKey = <unset>,
rootTaskKey = <unset>,
}
  1. The task is hung and needs to be cancelled, use the command:vim-cmd vimsvc/task_cancel task_id

Note: Please note that not all tasks can be canceled. For instance, in the example above we see the snapshot task has the cancelable flag set to false (cancelable = false).

  1. Shutdown the virtual machine using the VMID found in Step 3 and run this command:vim-cmd vmsvc/power.shutdown VMID

Note: If the virtual machine fails to shut down, run this command to hard power-off the VM:

vim-cmd vmsvc/power.off VMID

Example output:

Using esxcli

  1. Log in as root to the ESXi using SSH.
  2. Get a list of running virtual machines, identified by World ID and Display Name by running this command:
    esxcli vm process list

Example output:

  1. Take a note of the world ID of the non-responsive virtual machine. For example in step 3 the World ID is 2750434.
  2. Power off the virtual machine from the list by running one of these commands:esxcli vm process kill -t=soft -w=WorldID or esxcli vm process kill -t=hard -w=WorldID or esxcli vm process kill -t=force -w=WorldID

Note: These command provide different levels of force to stop the virtual machine:

  • Soft is the most graceful
  • Hard performs an immediate shutdown
  • Force should be used as a last resort
  1. If the VM fails to stop even after running the „esxcli vm process kill“ command, evacuate all other VMs off the ESXi host and restart the ESXi itself.

Using esxtop

Killing a virtual machine using esxtop is equivalent to a forced hard shutdown with esxcli.

  1. Log in as root to the ESXi host using SSH
  2. Show a list of the currently running virtual machines with esxtopesxtop
  3. Press „Shift-V“ to show only running virtual machines.
  4. Press „F“ to add new fields, and then „C“ to select the LWID (Leader World Id) field. Press „Enter“ to apply the change
  5. To kill one of the virtual machine processes, Press „K“ and copy the LWID from the unresponsive VM you wish to kill.

How to establish Bluetooth serial communication between two Pi 3’s

This is a guide on how to get Bluetooth communication working between two Pi 3’s using the on-board Bluetooth chips which was made possible by the raspberry pi forum and the user Douglas6 (Thanks again!).

Also I saw that somebody asked for something like this a few days ago so hopefully it help that person too.


This guide assumes that you are using Raspbian but since all the pairing and whatnot will be handled from the terminal (using generic programs) and not the GUI, I bet it would work for other distros.

Your bluetooth chip needs to be detected and working in order for this tutorial to be any use, there are a lot of posts on this sub to help you with that 🙂

I haven’t swapped out a Pi zero W for one of the Pi 3’s in this configuration, but I imagine the instructions for this would work for a zero W as well.


You’ll want to get familiar with bluetoothctl as it’s pretty important and very helpful when you know what the commands do. The help function tells you about all you need to know.

bluetoothctl
[bluetooth]#  help

Step 1: Update both your boards using and make sure that bluez and pi-bluetooth are installed (do this on each board)

sudo apt-get dist-upgrade
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install bluez pi-bluetooth python-bluez

Step 2: (Only sometimes necessary) Make sure that both the Bluetooth chips are not blocked using (on each)

sudo rfkill unblock all

Step 3: Pair the boards with one another First, make sure the Buetooth controller is powered (it usually already is)

bluetoothctl
[bluetooth]#  power on

Make the board discover-able

[bluetooth]# discoverable on

Set board as pair-able

[bluetooth]# pairable on

Repeat for the other board.

Now turn scanning on for one or both boards

[bluetooth]#  scan on

Since both boards are discover able, at this point you should see Bluetooth addresses popping up like this

Discovery started
[CHG] Controller B8:27:EB:7B:F3:62 Discovering: yes
[NEW] Device 80:7A:BF:0D:A8:68 HTC BS 681DC1
[NEW] Device 80:7A:BF:10:D4:D4 HTC BS D4D068
[NEW] Device B8:27:EB:25:95:F5 raspberrypi

That last one is the other R pi. Notice the Bluetooth address listed. I’ll refer to in a general sense with <bdaddr>.

Pair the boards with one another

[bluetooth]# pair <bdaddr>

Remember that <bdaddr> is the address of the other board, the one you are pairing with. It should pair and then you’ll get a GUI message asking you to pair and whatnot.

Answer yes to all of these.

An error gets thrown and the devices will disconnect. This is normal at this point

In one of the terminals you should have gotten a message that says

[CHG] Device <bdaddr> Paired: yes
Pairing successful
[CHG] Device <bdaddr> Trusted: yes

The devices need to be paired and trusted before moving on. To make sure that they are, run

bluetooth]# info <bdaddr>

and it should look something like this

[bluetooth]# info B8:27:EB:25:95:F5
Device B8:27:EB:25:95:F5
    Name: raspberrypi
    Alias: raspberrypi
    Paired: yes
    Trusted: yes
    Blocked: no
    Connected: no
    LegacyPairing: no
    UUID: Serial Port               (00001101-0000-1000-8000-00805f9b34fb)
    UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
    UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
    UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
    UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
    UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
    Modalias: usb:v1D6Bp0246d0517

If they aren’t trusted, use

    bluetooth]# trust <bdaddr>

So that both are trusted


Ok, hopefully that all worked out. Up until this point, everything could have been done through the GUI but now some additional work is required to prevent errors from being thrown when we try to connect.

Note: We have paired and trusted these devices to one another. This is a ‚permanent‘ action in that it lasts until you de-pair and de-trust them a.k.a. remove the device. Connecting is a different process that must be done each time they are turned off, taken out of range of one another, disconnected, etc.

Connecting is the persistent issue we run into at this point. Some config editing is required to fix it.


Step 4: Edit /etc/systemd/system/dbus-org.bluez.service

sudo nano /etc/systemd/system/dbus-org.bluez.service

Add a -C to the line

ExecStart=/usr/lib/bluetooth/bluetoothd

So that it looks like

ExecStart=/usr/lib/bluetooth/bluetoothd -C

And then add the following line below it

ExecStartPost=/usr/bin/sdptool add SP

So now the file has

ExecStart=/usr/lib/bluetooth/bluetoothd -C

ExecStartPost=/usr/bin/sdptool add SP

Do this on both and then reboot them. What this did was add a compatibility flag so that the chips run in compatibility mode and then we added a Serial Port Service (SPP) such that these things happen each time we boot.


Now that they are rebooted, we need to check and make sure that the SPP is actually running like we want it to. Use

sudo sdptool browse local

And you should see

Browsing FF:FF:FF:00:00:00 ...
Service Search failed: Invalid argument
Service Name: Serial Port
Service Description: COM Port
Service Provider: BlueZ
Service RecHandle: 0x10001
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Serial Port" (0x1101)
    Version: 0x0100

A lot of this info is not important but I included so you could recognise this particular block of text it in the terminal.


Ok, now that SPP is running on both boards, we can begin setting up our connection.

Step 5: Create server and client.

You can quickly test whether the boards accept a connection by running

sudo rfcomm watch hci0

on one board and then after that (do this on the other board)

sudo rfcomm connect hci0 <bdaddr>

where <bdaddr> is the address of the board ‚watching‘. If all goes well, on the server (1st) board you should see

Waiting for connection on channel 1
Connection from B8:27:EB:25:95:F5 to /dev/rfcomm0
Press CTRL-C for hangup

And on the client board you should see

Connected to /dev/rfcomm0 to B8:27:EB:7B:F3:62 on channel 1
Press CTRL-C for hangup

If you are here then you are basically home free. If you want to test out sending text over this serial connection, close the existing connection (this disconnects the boards) and then navigate to

/usr/share/doc/python-bluez/examples/simple/

And find the files named rfcomm-server.py and rfcomm-client.py.

Move copies of these files to your desktop (if you want). Edit the client file and set the addr variable equal to <bdaddr> of the other board (it’s a string so use „ADDRESS“).

Remaining paired and trusted (but not connected), run the sever file as root on one Pi and the client on the other. You should get a connection and be able to type stuff and receive it on the other. Congrats, you did it! Now feel free to edit the example files to suit your needs or roll your own using something other than pyserial.

2 Ways to Reset All Group Policy Settings to Default

Way 1. Reset Group Policy Settings via Local Group Policy Editor

You can use Local Group Policy Editor to reset all Group Policy settings to default in Windows 10.You can press Windows + R, type gpedit.msc in Run dialog, and hit Enter to open Local Group Policy Editor in Windows 10.

In Group Policy Editor window, you can click as following path: Local Computer Policy -> Computer Configuration -> Administrative Templates -> All Settings.

Next you can click State column in the right window, and it will display the policy settings by category. You can easily find the Enabled/Disabled policies at the top.

Then you can change the state of those policies from Enabled/Disabled to Not Configured.

Continue to find the following path in Group Policy Editor: Local Computer Policy -> User Configuration -> Administrative Templates -> All Settings. And do the same to change the modified Group Policy settings from Enabled/Disabled to Not Configured. Save the changes.

To make the resetting take effect, you can restart your computer, or open elevated Command Prompt, and type gpupdate.exe /force, and hit Enter to execute the command.

By default, all policies in Group Policy Editor are set to „Not Configured“. By doing so, you can reset all Group Policy settings to default in Windows 10.

If you want reset specific modified Group Policy setting to default, you can find that policy in Group Policy Editor and do the same to reset individual policy setting to default in Windows 10.

Way 2. Reset Group Policy Settings to Default with Command Prompt

If you don’t know which policies you have modified, you can also use Windows Command Prompt to reset all Group Policy settings to default in Windows 10.

By deleting the Group Policy settings folder from your computer hard drive, you can reset all the policies to default. Check how to do it.

  • Click Start, type cmd, right-click Command Prompt app to choose Run as administrator. This will open elevated Command Prompt in Windows 10.
  • Next you can type the command: RD /S /Q „%WinDir%\System32\GroupPolicy“ in Command Prompt window, and hit Enter to run the command.
  • Continue to type this command: RD /S /Q „%WinDir%\System32\GroupPolicyUsers“, and hit Enter.
  • Then you can type the command: gpupdate /force, and hit Enter to update the Group Policy settings. Or you can restart your Windows 10 computer to make these changes take effect.

Raspberry Pi replace kernel offline

It’s not that simple. But you can repair things on your RPi if you have (or can make) a second bootable SDCard.

Get your second SDCard with Debian and boot your RPi from that. Get your „broken“ SDCard in a USB reader, insert that in your RPi.

With chroot:

for i in /dev/sda*;do sudo umount $i; done
sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot
sudo mount -o bind /dev /mnt/dev
sudo mount -o bind /sys /mnt/sys
sudo mount -t proc proc /mnt/proc
sudo mount -o bind /dev/pts /mnt/dev/pts

cd /mnt
sudo chroot .
sudo rpi-update
exit
cd /
for i in t/boot t/dev/pts t/dev t/sys t/proc t; do umount /mn$i; done
poweroff

With rpi-update only, when chroot does not work:

To check which device is used for the SD card that needs to be rescued: fdisk -l
In my case: /dev/sda

sudo mkdir -p /mnt/rescue/{boot,root}
sudo mount /dev/sda1 /mnt/rescue/boot
sudo mount /dev/sda2 /mnt/rescue/root
sudo ROOT_PATH=/mnt/rescue/root BOOT_PATH=/mnt/rescue/boot SKIP_BACKUP=1 rpi-update
umount /mnt/rescue/{boot,root}

MAKE A PASSWORD PROTECTED ZIP FILE

This article explains how to make an encrypted (password protect) compressed file also referred to as an archive file.

Note: The built in Windows compression tool cannot password protect a compressed file; therefore a third-party application has to be used. In this article we use 7-Zip utility which is licensed under the GNU LGPL/GNU LGPL + unRAR and hence is free to download and use.

What to do

  1. Download the 7-Zip installer for your computer from www.7-zip.org. Run the program and install 7-Zip to your computer.
  2. In Windows Explorer, browse to the file you want to compress with 7-Zip.
  3. With the file/files/folder highlighted right-click on one item and from the sub menu select 7-Zip Add to archive….
  4. If you are sending the file to another person, who may not have 7-Zip installed, change the Archive format option from the default 7z to zip.
  5. Under the heading Encryption enter a password in the first field, and reenter the same password into the second password field. Ensure you do not forget the password you entered as you will be prevented from opening files inside the archive in the future.
  6. You may now click OK to create the compressed archive.

Note: Not all compression programs can open archives protected with AES-256 encryption so the recipients may have a problem opening the archive, or you may have a problem opening the file on another computer. Consider the level of protection required for the files and select the method of encryption that is appropriate.

  • Either leave the Encryption method as ZipCrypto to maximize compatibility with other compression programs. If you are sending the file to another person their compression program will most likely open .zip files encrypted with the ZipCrypto standard.
  • Or change the Encryption method to AES-256 if you need maximum security protection for the file/files/folder contained inside the archive.

You will have a new file with a .zip file extension in the same folder as the file/files/folder you selected to compress in step three.

If you open the zip and then try to open a file inside the zip file you will be prompted for the password you set previously.

Distribution Upgrade OpenSUSE

Before you begin

Make sure that you read the list of annoying bugs for the new version you are going to install. Some of them could affect the update process. Usually, some solution or workaround is listed alongside the bug, so make sure that you are prepared for upcoming problems.

Also, read the Release Notes which list changes and glitches in the new release.

Upgrading from the command line

The following steps show how to upgrade to 15.3:

1. Update the repos

Check if your Leap repos defined in /etc/zypp/repos.d/ are using the $releasever variable already. If they are still hard-coded with a particular Leap version number, then you need to modify them first. For example, assuming your current version is Leap 15.2, then this can be done with

sudo sed -i 's/15.3/${releasever}/g' /etc/zypp/repos.d/*.repo

2. Refresh with the new repos

Switch and refresh all repositories to 15.3

# zypper --releasever=15.3 refresh

3. Execute the full distribution upgrade

Now execute the full distribution upgrade.Warning: It is strongly recommended that you run the upgrade outside the X-window graphical mode. Thus it is recommended you run the command from either runlevel 3 (text + network), or a virtual console. Unfortunately many times the WIFI connection is managed/available only in runlevel 5, so a virtual text console may be best while staying logged into the graphical console behind the scenes. People had their X session stopped/crashed during the upgrade, causing the upgrade to abort, which in turn left the system in an inconsistent state. To change to runlevel 3, see SDB:Switch_runlevel. To remain in runlevel 5, but use a „virtual console“, type control-alt-F1 (as an example).

# zypper --releasever=15.3 dup --download-in-advance --auto-agree-with-licenses --allow-vendor-change

With the above command, zypper will download all packages in advance – which is more reliable if your internet connection may fail. To download packages in heaps and install them in heaps, use:

# zypper --releasever=15.3 dup

Once the dup is finished, openSUSE sets the releasever variable to the new version.If you did the above dist upgrade before the official release date (eg.2021-06-02 for Leap 15.3), you may have installed a Release Candidate (RC) or a milestone version and will need to repeat the final zypper dup step now to receive the final release.

4. Reboot

After upgrading, a reboot is recommended to start the new kernel and newer versions of everything.

5. Add extra repositories

Search for updated openSUSE Leap 15.3 compatible third-party repositories that you used before — if you still need them — and add them.Warning: Use with caution. Using third-party repositories may break your system or cause instabilities.

zypper addrepo --name <name> <url> <alias>

Or, if you have URL of a .repo file:

# zypper ar <url.repo>

Executing zypper up may be enough to update your software from these extra repositories.

6. Afterwards

Discover and enjoy :)In addition, zypper up can be run from time to time to ensure you have the latest available packages from the various repositories that you have enabled. YOU (Yast Online Update) only addresses security updates from the official repositories.

Windows Fehler 10016: Quelle DistributedCOM – Problemlösung

Die Fehlermeldungen 10016 in der Ereignisanzeige von Windows (ab Versionen Vista bis und mit Windows 8) treten wieder häufiger auf und können unter Umständen ein System ausbremsen. Der Fehler liegt in fehlenden Berechtigungen in den Komponentendiensten (comexp.msc) von Windows. Diese können meist nicht so einfach verändert werden, da die Einstellungen dazu deaktiviert (ausgegraut) sind. Außerdem ist meistens ein wenig Detektivarbeit angesagt, um herauszufinden, welcher Dienst in den Komponenten (z.B. IPBusEnum) zuständig ist und erhöhte Rechte benötigt.
Die Ursache liegt im neuen Schutz ab Windows Vista für die DCOM-Dienste. Der alleinige Besitzer ist der „TrustedInstaller“. In der Registry muss erst der Besitz geändert werden, damit man in den Komponentendiensten Änderungen vornehmen kann.

Am Beispiel dieser Fehlermeldung möchte ich ein wenig näher darauf eingehen und einen möglichen Lösungsansatz erläutern:
Durch die Berechtigungseinstellungen (anwendungsspezifisch) wird der SID (S-1-5-18) für Benutzer NT-AUTORITÄT\SYSTEM von Adresse LocalHost (unter Verwendung von LRPC) keine Berechtigung zum Start (Lokal) für die COM-Serveranwendung mit CLSID
{C97FCC79-E628-407D-AE68-A06AD6D8B4D1} und APPID {344ED43D-D086-4961-86A6-1106F4ACAD9B} gewährt. Die Sicherheitsberechtigung kann mit dem Verwaltungsprogramm für Komponentendienste geändert werden.Folgt man dieser Anweisung, wird man schnell herausfinden, dass oben genannte IDs nicht in den Komponentendiensten zu finden sind. Denn ruft man comexp.msc auf und wählt sich über Computer/ Arbeitsplatz/ DCOM Konfiguration durch, wird man geradezu erschlagen von Einträgen. Als Erstes gilt es herauszufinden, welche AppID auf welchen Dienst zugreift.

Dazu gehen wir wie folgt vor:

1. Stellen Sie sicher, als Administrator an Ihrem Computer angemeldet zu sein.

2. Rufen Sie über den Befehl „regedit“ den Registrierungseditor auf.

3. Im Registry-Editor öffnen Sie die Suche über CTRL-F und geben (wie in unserem Beispiel) folgenden Schlüssel (den Sie aus der Ereignisanzeige am Besten mit CTRL-C kopieren) ein:
{344ED43D-D086-4961-86A6-1106F4ACAD9B}
(bei anderen betroffenen Registry-Schlüsseln mit dem Fehler 10016, muss natürlich der entsprechende gesucht werden)
und bestätigen „Weitersuchen“ mit OK.

4. Das erste Ergebnis werden wir in HKEY_CLASSES_ROOT\AppID\ finden. Und genau diesen Schlüssel brauchen wir. Denn dieser eröffnet uns den zuständigen Dienst in den Komponentendiensten. In unserem Fall der IPBusEnum.
Bitte lesen Sie dieses Tutorial vollständig genau durch, bevor Sie Änderungen an der Registry vornehmen.
(wie Sie Schlüssel in der Registry sichern, wird am Ende dieses Tutorials erklärt)

Zum Vergrößern Bild anklicken

5. Weiter geht es mit einem Rechts-Klick auf den Ordner {344ED43D-D086-4961-86A6-1106F4ACAD9B} in der linken Spalte. Dort wählt man über „Berechtigungen“ den Button „Erweitert“.

6. Der einzige Besitzer ist der TrustedInstaller. Nun gilt es, über das Register „Besitzer“ für Administratoren die Klickbox [Besitzer der Objekte und untergeordneten Container ersetzen] „aktiv“ zu setzen. Bestätigen Sie dies mit OK.

7. Wir haben nun den Besitz des Schlüssels dem angemeldeten Benutzer (als Teil der Administratoren-Gruppe des Systems) zugewiesen.
Nun wechseln Sie in das Register „Berechtigungen“ und setzen bei SYSTEM und Administratoren (bei beiden Gruppen- oder Benutzernamen) jeweils in der Klickbox „Vollzugriff“ das Häkchen „aktiv“.

Dann bestätigen Sie das Ganze mit „Übernehmen“ und „OK“. Diese Schritte garantieren uns nun den Vollzugriff für „Administratoren“ und „SYSTEM“ zu besagtem Schlüssel HKEY_CLASSES_ROOT\AppID\{344ED43D-D086-4961-86A6-1106F4ACAD9B}

8. Prüfen Sie nun noch einmal den Wert im Schlüssel von LocalService. In diesem Fall IPBusEnum. Denn dieser ist nun wichtig für die Suche nach dem richtigen Komponentendienst.

9. Nun geben Sie in die Suche von Windows den Befehl comexp.msc ein und starten diesem mit „Als Administrator ausführen“. Danach wählen Sie über Computer -> Arbeitsplatz/ zu DCOM Konfiguration.

10. In der Spalte auf der linken Seite wählen Sie nun den Eintrag IPBusEnum über Rechts-Klick und öffnen die „Eigenschaften“.
Sollten hier die Einträge immer noch ausgegraut (nicht zu verändern sein), muss u. U. nach den Berechtigungsänderungen in der Registry (Punkt 1 – 7) der PC einmal neu gestartet werden, um bei Punkt 9 weiter zu fahren.

11. Wechseln Sie in das Register „Sicherheit“. Wählen Sie den „Bearbeiten“ – Button unter „Start und Aktivierungsberechtigungen“ und setzen dann das Häkchen bei SYSTEM -> Lokaler Start -> „Zulassen“. Nun bestätigen Sie die Änderungen mit OK.

Von nun an gehören Fehler IDs 10016 in der Ereignisanzeige der Vergangenheit an.

Wichtig bleibt anzumerken… Dieser Workaround kann angewendet werden, sofern man sich sicher ist, die richtige AppID herausgefunden zu haben. Bei Fragen dazu stehen wir im Forum gerne zur Verfügung.

Arbeiten und Änderungen an der Registry von Windows sind immer mit Vorsicht auszuführen. Ist man unsicher, empfiehlt es sich, die zu bearbeitenden Registry-Schlüssel über die Funktion „Exportieren“ unter Vergabe eines eindeutigen Namens zu sichern. Dieser kann bei möglichen Problemen wieder über Rechts-Klick der „.reg-Datei“ und „Zusammenführen“ wiederhergestellt werden.

Disable winmail.dat(TNEF) in MS Outlook

Disable TNEF using the Registry Editor

If all the above method fail, you can resort to entirely remove TNEF by altering your registry settings. It will be a rather harsh way of doing that, and I only suggest it to System Administrator who know what they’re doing. Take in mind that perform this task will also disable each Outlook TNEF-based feature, such as the built-in Voting System and Meeting Manager.

  • Close Outlook
  • Launch the Registry Editor from the Start menu by selecting Run, then typing regedit and pressing ENTER.
  • navigate through the following registry key:
    • Outlook 2007:  HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Preferences
    • Outlook 2010:  HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Preferences
    • Outlook 2013:  HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Preferences
    • Outlook 2016:  HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences
  • Add a new DWORD entry with the following name: DisableTNEF, and give it a value of 1.
  • Close the Registry Editor.
  • Restart Outlook.

Update Oneplus OTA without loseing root

If you want to do the OTA in TWRP:

  1. Download the full OTA zip, Disable all your Magisk modules and reboot to TWRP.
  2. Flash the full OTA zip (it will flash to the inactive slot and restore to the stock boot image, so no TWRP and Magisk in the inactive slot after this).
  3. Flash the TWRP installer (it will install TWRP to both slots).
  4. Choose reboot to TWRP, now you are in the new slot with an updated system, flash Magisk
  5. Reboot to the system, re-enable your Magisk modules and reboot