Playing Android Games On Your Windows PC

And now, for something completely different ūüôā

I once owned an Android phone. I didn’t only use it for making calls, I also played some games on it. When I disposed of the phone and didn’t get another Android phone, I had a problem. I still wanted to play my games.

After some searching, I found the answer: An Android emulator! You can download the BlueStacks App Player for Windows here. This App Player is free. It only asks to install some sponsored games while you use it. You don’t have to run them, but they have to be installed. Beside that, you’re totally free to install and run any app that you can find in the Play Store. You have to have a Google account, just as when using Android natively on your device.

Now just run the app…


Install your favorite game (in this screenshot, I’m updating)..


And play!


Alternatively, you can use Andy¬†to play your Android apps. It’s also free. Have fun!


Securing your browsers: Internet Explorer

As third and last, I’ll show you how to secure your browser settings for Internet Explorer.

Internet Explorer is somewhat different because it doesn’t have it’s own settings for cipher suites. It gets those from the operating system. In Windows they are implemented in one of the SSPI’s namely¬†SChannel. So to enable or disable cipher suites in IE, you need to enable or disable them in Windows.

First, let’s take care of the obvious. In IE there is an SSLv3 setting in the Advanced tab of the Internet Options. Uncheck this and IE will be POODLE-proof. SSL 2.0 should be unchecked by default.


Now, to disable cipher suites we could edit the registry. This is complicated and error prone, so we are going to use a tool. Download IIS Crypto here. I recommend version 1.6 GUI for .NET 4.0.

Start the tool with elevated privileges and have most of the work done for you¬†by clicking the Best Practices button. You’ll have to Press the Apply button and restart for the changes to take effect.

I have edited the cipher suite order and put the ECDHE_ECDSA ciphers at the top of the list, followed by the ECDHE_RSA ciphers. I have tried disabling MD5 hashing but found that some applications for RDP were not working anymore. Disable every protocol before TLS 1.0 and every cipher suite above Triple DES 168. I tried disabling Triple DES 168, but some websites wont work anymore because they are not updated to use the newer Elliptic Curve cipher suites yet. Please test what works for you and post in comments.




As you can see, I disabled all TLS_DHE_DSS suites and the RC4 suite. I use the 3DES_CBC suite as a fallback suite.

I also disabled a few RSA SHA256 and RSA SHA384 suites because Microsoft released a bad patch. The IIS Crypto site also tells us to disable these:


This concludes my ‘series’ on how to secure your browser. It may be that these settings will be deprecated real soon. It might also be that you can use these safely for a few years. All depends on the progress and development in the field of cryptography. I will keep you updated.

A quick note on WSUS error 0x80072EFD (Send failed with hr = 80072efd)

After installing a new WSUS server, my test machine failed to make contact. I had created a copy of the current WSUS GPO, edited it to the new server and applied it to only my test Windows 7 machine. I received the following error in the C:\Windows\WindowsUpdate.log

2012-03-05 14:34:12:187 1024 2748 Agent *************
2012-03-05 14:34:12:187 1024 2748 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
2012-03-05 14:34:12:187 1024 2748 Agent *********
2012-03-05 14:34:12:187 1024 2748 Agent * Online = Yes; Ignore download priority = No
2012-03-05 14:34:12:187 1024 2748 Agent * Criteria = “IsInstalled=0 and DeploymentAction=’Installation’ or IsPresent=1 and DeploymentAction=’Uninstallation’ or IsInstalled=1 and DeploymentAction=’Installation’ and RebootRequired=1 or IsInstalled=0 and DeploymentAction=’Uninstallation’ and RebootRequired=1”
2012-03-05 14:34:12:187 1024 2748 Agent * ServiceID = {XXXXXXX-E39D-4DA6-8A4B-XXXXXXXXXX} Managed
2012-03-05 14:34:12:187 1024 2748 Agent * Search Scope = {Machine}
2012-03-05 14:34:12:236 1024 2748 Setup Checking for agent SelfUpdate
2012-03-05 14:34:12:269 1024 2748 Setup Client version: Core: 7.5.7601.17514 Aux: 7.5.7601.17514
2012-03-05 14:34:12:279 1024 2748 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\
2012-03-05 14:34:12:353 1024 2748 Misc Microsoft signed: Yes
2012-03-05 14:34:15:667 1024 2748 Misc WARNING: Send failed with hr = 80072efd.


2012-03-05 14:34:25:587 1024 1a78 AU # WARNING: Search callback failed, result = 0x80072EFD
2012-03-05 14:34:25:587 1024 1a78 AU # WARNING: Failed to find updates with error code 80072EFD
2012-03-05 14:34:25:587 1024 1a78 AU #########
2012-03-05 14:34:25:587 1024 1a78 AU ## END ## AU: Search for updates [CallId = {XXXXXXX-9BE7-4DBC-8EC8-XXXXXXXXXX}]
2012-03-05 14:34:25:587 1024 1a78 AU #############

After some Googling it was clear it had something to do with the network. But after all usual network troubleshooting I wasn’t any closer to a solution. I decided to check the IIS server and finally got a bright moment. I installed the WSUS server on a clean Windows Server 2008 R2 SP1 installation. But I the old server has many services installed. Thus the new WSUS website was installed in IIS on port 80 while the old server was using port 8530. And because I copied the GPO and only adjusted the FQDN, it was still pointing to port 8530!

Instead of adjusting the GPO, I decided to bind the WUS website to port 8530 too. This way, when migrating to the new WSUS server, only the FQDN had to be changed.

I now got this documented, so I hope I will never waste another minute on this.

%d bloggers like this: