Recently I encountered issues starting my TeamSpeak server after updating it from version 18.104.22.168 to 22.214.171.124.; it would immediately crash with a blank error log. Apparently TeamSpeak Server 3.0.13 onwards requires the 32-bit Visual C++ Redistributable for Visual Studio 2015 to be installed. Yes, the 32-bit variant, even if your OS is 64 bit. So, should you encounter immediate server crashes after updating your TeamSpeak server to version 3.0.13, try downloading and installing the 32-bit variant of Visual Studio 2015 run-time from here: https://www.microsoft.com/en-us/download/details.aspx?id=48145
PS. In case you missed the release notes of TeamSpeak Server 3.0.12, as of that version, the server binaries file names do NOT contain platform suffixes any more. They’re all called “ts3server” now, so don’t forget to delete the old/obsolete binary including the platform suffix from your TeamSpeak Server installation folder (else it will crash as well…)
Nowadays it’s dead easy to schedule a PHP script as a cronjob/crontab in Plesk Onyx for Windows. However, in the previous versions, Plesk did not supply a sample syntax for scheduled tasks. Most examples found on the interwebs assume that you’re running Plesk on Linux, but if you are like me and run Plesk on Windows, that syntax is just plain wrong.
This small ‘note to self post’ shows how to correctly schedule a PHP script in Plesk for Windows for those of you who are still running an older version of Plesk :)
Step 1. Open Plesk and search for Scheduled Tasks
Step 2. Create a new cronjob/crontab as shown above. Adjust the parameters to your liking. In this example, I’ve scheduled the particular .php script to run every 5 minutes of each day of the week.
Step 3. You’re done! In the end, your finished cronjob/crontab should look like in the image above. If desired, you can also run it on demand by clicking Run Now.
Recently I’ve started to play around with Azure, Microsoft’s cloud. In this blogpost, I’ll be sharing some of my initial findings, which might prevent you from making the same rookie mistakes as I did ;)
VMs are automatically allocated a dynamic WAN (‘internet facing IP address’) in order to communicate with the internet. This causes the IP address to change when you stop and start the VM, for example using auto-start/auto-stop as described above. You can specify a DNS domain name label for a public IP resource, which creates a mapping for domainnamelabel.location.cloudapp.azure.com to the public IP address in the Azure-managed DNS servers. For instance, if you create a public IP resource with contoso as a domainnamelabel in the West US Azure location, the fully-qualified domain name (FQDN) contoso.westus.cloudapp.azure.com will resolve to the public IP address of the resource. This is particularly helpful in case of using a dynamic IP address. Should you not want this, you can assign a static IP to the VM. However, you cannot specify the actual IP address assigned to the public IP resource. Instead, it gets allocated from a pool of available IP addresses in the Azure location the resource is created in. For more information, visit: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-ip-addresses-overview-arm
It’s possible to delete the VM and preserve the static IP address, for example to assign to another/new VM. In order to do so, do not delete the entire resource group that is associated with the IP address. Instead, shutdown the VM, then delete the NIC associated with the static IP you want to preserve. Then delete all other components in the resource group except for the IP you want to preserve. Please do note that IP addresses cannot change resource groups, so in order to re-use the IP address, you need to create a new VM (or load balancer) in the same resource group as the IP address.
VMs in a DevTest lab are deployed without a Network Security Group (also known as a firewall) within Azure. They only come with the default Windows Firewall running on the machine itself. Should you want a NSG/Firewall within Azure as well, you can deploy one yourself in the same resource group and assign it to the VNet of the VM you created in the DevTest lab. Please do note that this requires you to forward ports in twofold; one time within the VM itself in the Windows Firewall and the second time from within the NSG/Firewall in the Azure portal. Image credit: http://pumpingco.de/your-own-game-server-on-azure-create-a-dedicated-counter-strike-server/
This is also the case with normal VMs (i.e. VMs that are not created in a DevTest lab) as they come with a NSG/firewall by default.
Azure offers two types of storage disks: SSD (Premium storage) and conventional HDD (Standard storage). SSD disks come in 3 sizes, 128GB, 256GB, 512GB. HDD disks have a flexible/user chosen size which can vary up to 1TB. You need to create a software RAID in order to get a large volume/disk. Premium Storage supports DS-series, DSv2-series, GS-series, and Fs-series VMs. You can use both Standard and Premium storage disks with Premium Storage supported of VMs. But you cannot use Premium Storage disks with VM series which are not Premium Storage compatible (for example the A-series or Av2-series). If you’re using standard storage, you’ll only be charged for the data you’re storing. Let’s say you created a 30 GB VHD but storing only 1 GB of data in it, you will only be charged for 1 GB. All empty pages are not charged. HOWEVER, if you’re using SSD (premium storage) you pay for the FULL SSD disk regardless of how much data you stored and empty pages are charged… so it becomes expensive pretty quick. For more information, visit https://azure.microsoft.com/nl-nl/blog/azure-premium-storage-now-generally-available-2/ and https://docs.microsoft.com/en-us/azure/storage/storage-premium-storage
Azure Storage provides the capability to take snapshots of your VMs. In order to take snapshots of your VM, you need a Recovery Services vault. A Recovery Services vault is an entity that stores all the backups and recovery points you create over time. The Recovery Services vault also contains the backup policy applied to the protected files and folders. Previously, when you created a backup vault you had the option to select locally redundant storage (LRS) or geo-redundant storage (GRS). This has now changed and you do not have the option during the vault creation.
Now, by default, your vault will be created in a GRS, which costs (way) more than LRS (almost double!). If you want to switch to LRS, you must do so after the vault has been created but PRIOR to registering any items to the vault. You cannot switch the storage type of your Vault after you registered any items to it! To do this, simply access the Configure tab of your backup vault and change the replication from the default of GRS to LRS. Don’t forget to click Save…
When you create a VM in Windows Azure you are provided with a temporary storage automatically. This temporary storage is “D:” on a Windows VM and it is “/dev/sdb1” on a Linux VM and is used to save the system paging file. This temporary storage must not be used to store data that you are not willing to lose, as there is no way to recover any data from the temporary drive. The temporary storage is present on the physical machine that is hosting your VM. Your VM can move to a different host at any point in time due to various reasons (hardware failure etc.). When this happens your VM will be recreated on the new host using the OS disk from your storage account. Any data saved on the previous temporary drive will not be migrated and you will be assigned a temporary drive on the new host. Because this temporary storage drive is present on the physical machine which is hosting your VM, it can have higher IOPS and lower latency when compared to the persistent storage like data disk. The temporary storage provided with each VM has no extra cost associated with it for storage space as well as for transactions. For more information, visit: https://blogs.msdn.microsoft.com/mast/2013/12/06/understanding-the-temporary-drive-on-windows-azure-virtual-machines/ If your application needs to use the D drive to store data, you can to use a different drive letter for the temporary disk. However, you cannot delete the temporary disk (it’ll always be there), you can only assign it a different drive letter. For instructions on how to do so, visit https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-classic-change-drive-letter
About half a year ago, I bought a Mikrotik RouterBoard RB962UiGS-5HacT2HnT hAP AC (Phew! What a mouthful!). It’s a great router, or should I say routerboard, which has more features I could ever wish for… maybe even too many!
Nevertheless, out of the box, I was unable to visit my local NAS/Webserver using the WAN IP from my local network. After a quick Google DuckDuckGo search, I discovered that this requires a so-called ‘Hairpin NAT’. Basically, it reroutes all traffic sent to your WAN IP from your local network, back to (a specific IP address in) your local network. Graphically, it looks like this:
See the arrow which, with a little bit of imagination, looks like a hairpin? Hence the name…anyway, let’s continue!
However, the issue with most Hairpin NAT configurations you find online is that it requires you to have a static WAN IP, which I don’t have. Additionally, most tutorials use the terminal, whereas I prefer the graphical interface of Winbox. Therefore, I figured out how to setup a Hairpin NAT in combination with a dynamic WAN IP using Winbox myself and since ‘sharing is caring’, here’s how to do it:
Connect to your Mikrotik using Winbox
Select IP –> Firewall from the menu
Make sure that the default ‘defconf: masquerade’ rule is on top, which looks as follows:
Add a new rule as follows, name it ‘Hairpin NAT’, which looks as follows (replace 192.168.88.0/24 with your own local network IP range):
Add another rule. This rule will contain the IP and port you are trying to reroute. For example, lets say I want to connect to my local NAS running on IP 192.168.88.50 and port 1337 using my WAN IP, my rule would look like this: Don’t forget the exclamation mark in front of the Destination Address! Protip: You can add more ports in the same rule. Just split ranges with dashes like this: 1330-1337 and multiple ports with commas like so: 80,443,1330-1337
Done! You should now be able to access your NAS/Webserver using your WAN IP from your local network. Feel free to add more rules to your liking, but remember, the order is important. So first the ‘defconf: masquerade’ rule, then the ‘Hairpin NAT’ rule and then all other rules :)
For the past three days, I’ve been trying to fix several Perflib errors that were appearing in my Event Viewer. The errors cycled through like this:
The Open Procedure for service “BITS” in DLL “C:\Windows\System32\bitsperf.dll” failed The Open Procedure for service “ESENT” in DLL “C:\Windows\system32\esentprf.dll” failed The Open Procedure for service “Lsa” in DLL “C:\Windows\System32\Secur32.dll” failed The Open Procedure for service “MSDTC” in DLL “C:\Windows\system32\msdtcuiu.DLL” failed
They all had Event ID 1008 and Perflib as source. The only difference was it’s service- and DLL name.
Apart from these errors appearing in my Event Viewer, I didn’t notice anything strange with my computer; Everything was working like it should, so I had no idea what this could be causing and what (according to Windows) wasn’t working like it should. After a quick Google search, I found out that the error itself isn’t a big deal; It’s just saying it can’t collect performance data.
That was the easy part. Getting red of the errors is a whole different story. These errors got me technically stumped, as I’ve tried virtually every solution you can find on the web to no avail:
– I ran a virus scan as well as a malware scan, without success. – I ran a chkdsk, without success. – I ran sfc /scannow, without success. – I ran lodctr /r, without success. – I ran Microsoft’s SystemFileChecker tool to repair missing or corrupted system files, without success. – I removed and reinstalled the BITS, ESENT, LSA and MSDTC service without success.
This was driving me nuts. Since the error itself wasn’t really a big deal, I decided to disable the performance counters for the services that Windows was unable to collect performance data for. This can be achieved by using Extensible Counter List which can be downloaded here: http://download.microsoft.com/download/win2000platform/exctrlst/1.00.0.1/nt5/en-us/exctrlst_setup.exe After downloading and installing Extensible Counter List, go to C:\Program Files (x86)\Resource Kit and run Exctrlst.exe as Administrator. Next, find the service(s) in the list that Windows reports it is unable to collect performance data for and uncheck ‘Performance Counters Enabled’ for each service.
Although this doesn’t solve the initial problem why the errors are occurring, at least it helps you to get rid of them from Event Viewer (a.k.a. symptom treatment)…. But since the errors themselves aren’t a big deal, you should be fine.
A friend of mine was having issues booting his laptop. The BIOS recognized his SSD, an Intel SSD sa2bw120g3a, but Windows was nowhere to be found. Even bootable partition and hard drive managers showed no sign of the SSD. This got me thinking that the SSD was dead, which was odd, as the BIOS was still recognizing it.
Several minutes of Googling lead me into the right direction; My friend’s SSD was suffering from the 8MB bug that was discovered in (almost all) Intel SSD firmwares, back in July 2011. As my friend never encountered issues with his SSD and wasn’t up to date about this fact, he never updated his SSD’s firmware, which could have prevented this bug from happening.
The 8MB bug is caused by an unexpected power loss under specific conditions. This will reduce the capacity of the SSD to 8MB and change the serial number to “BAD_CTX 0000013x”. Once this error occurs, no data on the SSD can be accessed and the user cannot write to or read from the SSD. The only way to get the SSD back to work is to erase it. That’s right, all data on the drive is permanently lost.
Some people have been able to start from scratch by wiping the drive’s contents with utilities such as HDDErase and Parted Magic but this only works if your SSD is not ‘frozen’. And since my friend has all the luck in the world, sure enough his SSD was frozen. Fixing a frozen Intel SSD suffering from the 8MB bug requires a more technical approach but it’s no rocket science once you know what you have to do. So, let’s get started!
You need: – Hiren’s Boot CD / USB: http://www.hirensbootcd.org/hbcd-v132/ Update 21-11-2016: Mini Linux was removed from recent Hiren’s Boot CD versions. The last Hiren’s Boot CD to include Mini Linux is version 13.2 which you can download from the link above (scroll all the way down). – Physical access to your SSD (i.e. open up your computer case)
1. Insert Hiren’s Boot CD / USB into your computer and boot from it.
2. Select ‘Mini Linux’ from the menu and hit Enter.
3. Once Linux has loaded, right click on the wallpaper and select ‘Xterm’
4. A command prompt / terminal should open. Enter the following command to get a list of all available harddrives in your computer:
Locate your Intel SSD in the list and take a note of the device name, for example /dev/sda
5. Type the command:
sudo hdparm -I /dev/sdX
where sdX is your SSD device. This command will just print out some info about the drive. If you see in the output this: Serial Number: BAD_CTX that confirms that you are hit by this bug. If at the Security section it reads frozen you CANNOT continue, you have to use a workaround to eliminate the freeze before you can continue: Unplug and then replug the SATA data cable of your Intel SSD while the system is still powered on. So, leave your computer powered on, open up your case, locate the SATA data cable of your Intel SSD, unplug it and then replug it. This should unfreeze your SSD.
6. Type the command:
sudo hdparm --user-master u --security-set-pass SOMEPASS /dev/sdX
Again /dev/sdX is your SSD drive, and SOMEPASS is a password you want to set for the SSD. (This password doesn’t lock the SSD or anything similar, it is just needed for these low-level dealing with the SSD.) We will need that SOMEPASS later on, so remember it/write it down. (But after the secure erase this password will be reset anyway so it is not important in the longterm.)
7. Check the drive again:
sudo hdparm -I /dev/sdX
Now it should say enabled and not frozen at the security section:Security: Master password revision code = 65534 supported enabled not locked not frozen not expired: security count supported: enhanced erase
8. Type the command:
sudo hdparm --user-master u --security-erase SOMEPASS /dev/sdX
This issues the secure erase command. Again /dev/sdX is your SSD, SOMEPASS is the password set before. The completion of this operation can take a few minutes. After this your SSD should be functional, if not, try again with this command:
sudo hdparm –user-master u –security-erase-enhanced SOMEPASS /dev/sdX
This latter command takes much more time (30-40 minutes) and you will have to reset the password (with step 4.) before running it because SOMEPASS is likely already reset by the previous command.
9. After this check the drive again
sudo hdparm -I /dev/sdX
The BAD_CTX thing should be gone and your drive should be functional. You can now reinstall your O/S. After all this don’t forget to update the firmware of our SSD using Intel SSD Toolbox to prevent the bug from happening again in the future.
There are lots of tutorials online that show you how to move, or migrate if you will, your TeamSpeak 3 server from Windows to Linux, but there’s no guide that shows the other way around. One could say that this process is simply the same, only executed backwards. However, since most of them are outdated, for example most guides let you execute SQL queries to replace all the linux directory standards with windows standard which is no longer needed, I felt the need to write this up-to-date tutorial, in which I will explain how to move a Teamspeak 3 server from Linux to Windows. The process is no rocket science, so don’t worry.
In this particular tutorial, I will be moving TeamSpeak 126.96.36.199 on Ubuntu Server 12.04.5 LTS to TeamSpeak 3.0.11 on Windows Server 2008 R2. You can even migrate between versions, i.e. TeamSpeak 188.8.131.52 to TeamSpeak 3.0.11. That’s right, there’s no need to do an in-place update before you can migrate…. Now, let’s get going!
First, we need to copy the following files from our TeamSpeak 3 Linux server to our new Windows machine: licensekey.dat – Only applicable if you own a TeamSpeak 3 license. query_ip_whitelist.txt – Whitelisted IPs for the query interface query_ip_blacklist.txt – Blacklisted IPs for the query interface files/ – Any Icons, Avatars and files that were uploaded to the server. Be sure to copy the entire folder including any subfolders and files inside. ts3server.sqlitedb – The database, this file is the most important one and contains all the information about virtual servers, users, permissions, channels, groups etc. All Settings of the server instance and its virtual servers are contained in this file. Source: https://support.teamspeakusa.com/index.php?/Knowledgebase/Article/View/315/16/i-want-to-move-my-server-to-another-machine-which-files-should-i-copy
Hold your horses! In my introduction above, I mentioned that you can migrate between TeamSpeak versions withouth having to do an in-place update before. However, this *only* holds if you’re using a SQLite database, which is the case by default. This is because as of TeamSpeak Server 3.0.11, the MySQL database plugin has been replaced by a MariaDB plugin. Which means that if you were using a MySQL database for your TeamSpeak server, you need to migrate it to MariaDB, else your database will be incompatible with the latest TeamSpeak Server version. As SQLite is used by default, this is outside the scope of my tutorial and thus I will not be covering this. Here’s a free hint though: Read doc/update_mysql_to_mariadb.txt for instructions on how to update. Also note that the default character set for the database is now ‘utf8mb4’, which means the server needs to be at least MySQL 5.5.3 or MariaDB 5.5. Let’s continue :)
1) Login to your Linux server, navigate to your TeamSpeak 3 installation folder and copy the files listed above to your new Windows machine using your favorite method, i.e. flash-disk etc, to a temporary directory, for example C:\TS3Migration
Have you ever faced the problem where a legacy DOS or Windows 95 & 98 runs perfectly on Windows XP/Vista/7/8, with or without compatibility mode, but refuses to print? This is because legacy DOS or Windows 95 & 98 programs expect your printer to be connected to a LPT1 port, which is usually not the case anymore nowadays. If you want to enable printing to an USB or Network Printer for these legacy DOS or Windows 95 & 98 programs, follow these steps:
1) First, make sure you can print from within Windows to the desired printer, by printing a test page.
2) Next, go to Control Panel –> Printers All of your printers should be listed, including the printer you want to set up for DOS printing.
3) Right-Click on the name of the printer that you want to set up for DOS printing and choose “Properties” from the pop-up context menu.
4) Click on the “Ports” Tab at the top of the Printer Properties Window.
5) Make a note of the exact name of your current printer port.
6) Select the “Enable Printer Pooling” checkbox. i.e. be sure that the box is checked.
7) Scroll up and/or down through all of your listed ports and click the “LPT1” port to place a checkmark in it. Note: You should now have both LPT1 and your default printer port (from step 5) selected
8) Click “Apply” and “Ok”.
There you go! You should now be able to print from your legacy DOS/Windows 95 & 98 programs to your USB/Network printer The above steps essentially trick Windows to act as though the USB/Ethernet printer is connected to LPT1. No need to use expensive third party tools such as Printfil or DOS2USB… this will do the trick as well!
The Arcadyan VGV7519, also known as the KPN Experia Box v8, features an USB port, which can be used to turn your USB printer into a network printer. However, simply connecting your USB printer the USB port onto the router is not enough; Windows will not recognize the printer as a network printer. Instead, you have to install the printer manually, as if it was connected as a local printer. In this guide, I’ll explain how to setup your USB printer with the Arcadyan VGV7519 / Experia Box v8 and how to connect to your printer.
First, make sure your USB printer is connected to the USB port of your router and power on your printer.
Secondly, open a webbrowser and go to the web interface of your router by entering the IP address of your router into your web browser’s address bar. If you’re unsure what the IP address of your router is, try the default IP which is 192.168.2.254. If that doesn’t work, i.e. the web interface of your router does not show up, you can find it’s IP address by open the Network and Sharing Center in the Windows Control Panel; Click the name of your Internet connection, in my case Wireless Network Connection (TELUS2410).
Click the Details button to view more information about the connection.
Look for the IPv4 Default Gateway IP address in the details window. Type this IP address into your web browser’s address bar.
Type this IP address into your web browser’s address bar. The router’s web interface should now show up. Login using the administrator password, which is default either ‘admin’, ‘1234’ or blank (i.e. do not fill in anything).
Once logged in to the router’s web interface, go to Extras –> USB –> Enable USB function
Next, go to ‘Printer Server’ and check whether the Enable LPD-LPR Printer Server function is enabled. Also take note of the LPR queue name, which is ‘printer’ by default.
The web interface already reveals a little bit what we’re going to do next, as it says: “In order to do so, you need to set up a “local printer” using a “Standard TCP/IP Port” on each computer you wish to print from. The IP address of printer server is 192.168.2.254, and host name is router.” Let’s get going!
Choose Control Panel from the Start menu.
Click on Add a printer in the menu bar.
Click on Add a local printer.
Select Create a new port. Select Standard TCP/IP port from the drop-down menu and click Next.
In the Hostname or IP Address field, fill in the IP Address of your router. This is the same IP address you’ve entered earlier in your web browser to visit the web interface of your router, by default 192.168.2.254 The Port name field will automatically complete. De-select the checkbox for the Query the printer and automatically select the driver to use option and click Next.
Windows will now detect the remote host. This could take several minutes.
You will now be prompted to configure the TCP/IP port. Select Custom and click Settings… to open the configuation dialog.
Select LPR as the Protocol Provide the Queue Name from your router’s web interface, which is ‘printer’ by default. Check the LPR Byte Counting Enabled option, and make sure that SNMP Status Enabled is unchecked. Click OK.
Update your printer drivers from Microsoft by first selecting the Windows Update button before selecting a printer model. This could take several minutes.
Select the driver appropriate for the model of printer being installed. After selecting the driver from the list, click Next.
In case Windows detects that a driver is already installed for this printer, click the bullet next to Use the driver that is currently installed (recommended)
Enter a printer name that you would like to use and click Next.
Make sure the bullet is selected beside Do not share this printer
Click to put a check mark beside of Set as the default printer (if you do wish to make it your default printer)
Click Finish. Your printer should now be set up and ready to use.
In this tutorial I am going to show you how to root your Asus Transformer TF101 or Asus Transformer Prime TF201, running the latest version of Ice Cream Sandwich (ICS), which at the time of writing is 184.108.40.206 for the TF101 and 220.127.116.11 for the Prime TF201. The only way to root your tablet running 18.104.22.168 or 22.214.171.124 WITHOUT unlocking your bootloader, is to downgrade to an older firmware version, get root, upgrade back to the latest firmware version available and restore our root access using OTA Root Keeper. The benefit of this method is that you will not void your warranty, as your bootloader will remain locked. This whole process will take about 30 minutes to complete and will keep your data intact. I created this tutorial all by myself after I successfully rooted my Transformer Prime TF201 running 126.96.36.199 and a Transformer TF101 of a friend of mine running 188.8.131.52.
Rooting (and downgrading) is a complicated process. I’ve tried to make this tutorial as easy to follow as possible. It contains lots of screenshots, which are in Dutch (Nederlands) by the way, but I also assume you have basic computer knowledge. If you don’t even know what ‘rooting’ is, then this is not for you! In this tutorial I will be rooting my Transformer Prime TF201, but the process for the Transformer TF101 is exactly the same. Just make sure you don’t mix up the firmware numbers. I also would like to point out that I am not responsible for any possible damage that this process may cause to your tablet. Downgrading and rooting Android devices is highly experimental and may turn your device into worthless brick. Proceed at your own risk!! Last but not least: English is not my first language, so please excuse any spelling errors I’ve made below.
-Make sure your Transformer is FULLY Charged -Make sure your Transformer is NOT Docked -Make sure your Transformer’s bootloader is LOCKED, i.e. you are NOT running a custom ROM or have ClockworkMod flashed. -Make sure your firmware build number is equal to 184.108.40.206 if you have a Transformer TF101 or 220.127.116.11 if you have a Transformer Prime TF201 -Only use the ORIGINAL USB Cable, WITHOUT any USB extension cables -Take your time, don’t rush things and be patient. -Follow the instructions precisely and all will be OK!
Preparation: Backup Apps&Data
Let’s start by making a backup of our apps and data in case something goes wrong. Open up the Asus Back-up app. Accept the Terms of Agreement and click on ‘Start’.
In the right upper corner select ‘Data & Application’ as ‘Back-uptype’, click ‘Select all’ and click ‘Back-up’. The time it takes before the backup finishes depends on the amount of apps you have installed on your tablet. Just be patient.
Preparation: Download & Copy older firmware
Before we continue, we need to verify which exact firmware version our Transformer tablet is running. To do so go into ‘Settings’ –> ‘About Tablet’ and scroll down until the ‘Build- number’ appears, like so:
As you can see, my tablet is running the latest version of ICS available, which at the time of writing is 18.104.22.168 for the Prime TF201. But also note the ‘WW’ in front of the number, which means ‘WorldWide’. This is important because Asus releases different types of firmware versions for different countries. For example, Transformer tablets in the USA will have an ‘US’ prefix instead of the ‘WW’ prefix. When downgrading (or flashing a new ROM onto) your tablet, it is very important to make sure you have the correct corresponding firmware type. In other words: Do NOT flash a ‘US’ type firmware on your tablet if it originally was a ‘WW’ type tablet.This WILL cause problems!
Now that we know which firmware type our tablet has, in my case that’s ‘WW’, we need to download an older firmware for our tablet to be able to gain root access. This is needed because the latest firmware version we’re running (22.214.171.124) does not contain any exploits that we can use to gain root access directly. This is because Asus patches those exploits with every firmware update they release. However, older firmware versions do contain exploits to gain root access and thus we need to downgrade to one of those older firmware versions first before we can gain root access. If you have an Transformer TF101, I recommend downloading firmware version 126.96.36.199, which can be found here: WWversion: https://freek.ws/transformer/TF101/WW_epad-user-188.8.131.52.zip USversion: https://freek.ws/transformer/TF101/US_epad-user-184.108.40.206.zip Again, make sure to download the correct corresponding firmware type for your tablet, as explained above!
After you’ve downloaded the corresponding older firmware version for your tablet, you’ll end up with a .zip file. Unzip the .zip file, which will leave you with a ‘META-INF’ folder and a ‘blob’ file. You can delete the ‘META-INF’ folder; we only need the ‘blob’ file.
Connect your Transformer tablet to your computer using the original USB cable and copy the ‘blob’ file into the root of the INTERNAL STORAGE of your Tranformer (NOT the SDCard), like so:
Preparation: Change tablet settings
Before we can downgrade our tablet, we need to change some settings in our tablet. Before you continue, please disconnect the tablet from your computer! On your tablet, go to Settings –> Developer Options –> Click OK at the message that pops up –> place a checkmark at ‘USB debugging’ –> Click OK at the message that pops up. Also go to Settings –> Security –> place a check mark at ‘Unknown Sources’ –> Click OK at the message that pops up. Lastly, go to Settings –> Accounts & Synchronization –> Uncheck (remove) the check mark at ‘Start Asus Sync’.
Download ‘Downgrade Tool’
We now need to download a tool which will downgrade the firmware for us. This tool is no more than an automated version of a downgrade exploit invented by Wolf849 (1) and can be found here: https://www.freek.ws/downgrade_tool (2)
Once downloaded, you will end up with another .ZIP file. Again unzip this file and you’ll end up with a bunch of files. This .ZIP file also contains the Drivers we need to use in the next step!
Preparation: Install Drivers
Now connect your tablet to your computer again, using the original USB cable. Windows now probably will l complain a ‘Device driver software was not successfully installed’ in the right bottom corner of your screen.
To solve this, go ‘Start’, right click on ‘Computer’ –> ’Properties’.
In the new screen that pops-up (assuming that you’re running Windows 7) click on ‘Device Manager’, in the left upper corner.
You will now see a device called ‘Asus Android Composite ADB Interface’ listed under ‘Other devices’ with a yellow exclamation mark. Right click on it and select ‘Update driver’.
In the new screen that pops-up, select ‘Browse my computer for driver software’.
In the next screen, browse to the ..\Drivers\Android folder which was included in the .zip file you’ve downloaded above and click ‘Next’.
Your computer should now install the correct drivers for your tablet. If all went well, you should see this screen:
Click ‘Close’ and check if the ‘Asus Android Composite ADB Interface’ is now listed under ‘Asus Android Devices’ instead of ‘Other devices’, like so:
Preparation: Kill unwanted apps
Before we can downgrade, we need to make sure the apps ‘Asus Sync’ and ‘Splashtop Remote’ are not running. To do so (do NOT disconnect your tablet from your computer!) on your tablet go to Settings –> Apps –> All –> Search for ‘com.asus.pcsynclauncher’ and ‘Splashtop Remote’. Make sure to ‘Force stop’ both apps. To do so, click on them and press ‘Force stop’.
After Force stopping, the ‘force stop’ button will be greyed out which means the app is no longer running in the background.
We are now finally ready to downgrade our tablet. Open (by double clicking) ‘viperMOD Primer Tool v4.5 – Modded by bpear_v3.exe’ . You will see this screen: We need option 1, so press 1 on your keyboard and hit the Enter button to continue. NOTE: Although it says ‘Downgrade unrooted US Prime to .15’, this also works for WW Prime and also for US and WW TFT101. Don’t worry :)
You’ll get this screen: Hit the Enter button to continue. You’ll get this screen: Once again, hit the Enter button to continue. The downgrade process will now begin. DO NOT DISCONNECT YOUR TABLET FROM YOUR COMPUTER DURING THIS PROCESS! Disconnecting your tablet during the downgrade or rooting process can break your tablet and turn it into a unless (but very expensive) brick!
If all goes according to plan your tablet will reboot first, then the older firmware we’ve copied earlier (the ‘blob’ file) will be copied to the correct system folders (this can take up to 10 minutes, BE PATIENT!!) and then your tablet will reboot once again running the older firmware. While rebooting, the tablet will stop for a while displaying the Asus EEE Logo with a progress bar; Don’t worry – the bar will move in 1 minute or so. Just be patient! If the downgrading process has finished, you’ll see this screen: Hit the Enter button, followed by pressing 8 and hitting the Enter button to exit.
To verify if your tablet has indeed been downgraded successfully, go into Settings à About tablet and verify the ‘Build-number’. It should say ‘220.127.116.11’ if you have a Transformer TF101 or ‘18.104.22.168’ if you have a Transformer Prime TF201, like so: If that’s the case, we can proceed by rooting our tablet. If not, then you’ve done something wrong. Please start from the beginning and make sure you exactly follow each and every step precisely.
You’ll end up with another .zip file. Again unzip this .zip file somewhere and you’ll end up again with a bunch of files and folders.
Before we can root our tablet, we need to make sure again that the apps ‘Asus Sync’ and ‘Splashtop Remote’ are NOT running. Please see above on how to do this.
We now can finally root our tablet. Open (by double clicking) ‘viperMOD PrimeTime v4.5.exe’ . You will see this screen: We need option 1, so press 1 on your keyboard and hit the Enter button to continue. NOTE: Although it says ‘Root (only method for Prime on ICS v9.x.x.11)’, this also works for the Asus Transformer TF101 running 22.214.171.124 and Transformer Prime TF201 running 126.96.36.199. Don’t worry :) However, whatever you do, do NOT flash recovery if you’re NOT on a Prime. That option is ONLY for Prime TF201!!
Let’s continue. You’ll now get this screen: Hit the Enter button to continue.
You’ll get this screen: Once again, hit the Enter button to continue. The rooting process will now begin. Once again, DO NOT DISCONNECT YOUR TABLET FROM YOUR COMPUTER DURING THIS PROCESS!
If all goes according to plan some files will be transferred to your tablet first, the exploit will be used to gain root access and BusyBox will be installed. Finally your tablet will reboo and once rebooted it will be rooted! If the rooting process has finished, you’ll see this screen:
Hit the Enter button, followed by pressing 7 and hitting the Enter button to exit.
Protect Root with OTA RootKeeper
To verify that your tablet has indeed been rooted, go into the market, download ‘OTA RootKeeper’ and open it. On opening, a SuperUser prompt will popup asking if ‘OTA RootKeeper’ is allowed to get root permissions. Hit ‘Allow’ If correctly, OTA RootKeeper will confirm that your device is rooted: Now before we continue, it is important that we protect our root access. Like I said before, with every new firmware update Asus releases, they patch any exploits which will gain us root access. So to make sure we can safely upgrade to a newer firmware version (in our case 188.8.131.52 or 184.108.40.206), we need to protect our root access BEFORE upgrading. If you don’t do this, you will lose your root access and you can start all over again. I hope you understand the importance of this app, so whatever you do, DO NOT UNINSTALL OTA ROOTKEEPER! To protect your root access, press the ‘Protect root’ button in OTA RootKeeper. It’ll take just a few seconds. Once it has finished protecting our root access, you should see this:
Upgrade to latest firmware
Now we’re ready to upgrade back to the latest firmware available, in our case 220.127.116.11 for the TF101 or 18.104.22.168 for the Prime TF201 To do so, on your tablet, go to ‘Settings’ –> ‘About tablet’ –> ‘Update systemfirmware’. It should now say a new update is available and start downloading it. If it doesn’t say there’s an update available, just wait a couple of hours and try again. It should show up eventually. If still doesn’t show up after 24 hours, make sure you flashed the correct version of firmware (ie. WW if your tablet is a WW version). You can check the download progress in the notification area, in the right down corner of your tablet. If it has finished downloading, a notification will be placed in the notification area, in the right down corner of your tablet. Click on it and this screen will appear: Now hit Install and your tablet will upgrade to the latest firmware as it normally would do.
Restore Root using OTA RootKeeper
Finally, once the upgrade has finished, open OTA RootKeeper and restore your root access.
Congratulations! You’ve now successfully rooted your Transformer TF101 or Transformer Prime TF201 tablet, running the latest available firmware (22.214.171.124 or 126.96.36.199)! That wasn’t so hard, was it ;) ?