Quickly query a registry key

Sometimes you want to know quickly what a registry key is set to on a Windows machine.  Maybe you want to see what the windows update settings are because you are trying to deploy wsus.  Maybe you have just applied a security setting with GPO on a domain

From the command line you can quickly query the settings in the registry like this:

c:\>Reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
    ElevateNonAdmins    REG_DWORD    0x1
    DoNotAllowSP    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
    NoAutoUpdate    REG_DWORD    0x0
    AUOptions    REG_DWORD    0x3
    ScheduledInstallDay    REG_DWORD    0x5
    ScheduledInstallTime    REG_DWORD    0xb
    NoAutoRebootWithLoggedOnUsers    REG_DWORD    0x1
    RescheduleWaitTimeEnabled    REG_DWORD    0x1
    RescheduleWaitTime    REG_DWORD    0x5
    RebootRelaunchTimeoutEnabled    REG_DWORD    0x1
    RebootRelaunchTimeout    REG_DWORD    0x1e
c:\>

The /s switch shows all sub keys.  Note the key values are dispalyed in hexadecimal so ScheduledInstallDay of 0x5 is day 5, starting counting from sunday as 1 so Thursday.  ScheduledInstallTime of 0xb is 11 in decimal so 11am.


The quickest way I know to convert hexadecimal to decimal if you are not sure is to use google - a search for "0xb as decimal" in google shows the answer of 11 above the other search results.

Recycle bins - why so many and how to clear them

Each user has a separate recycle bin for each partition on a computer.  This is great as it means is Bob empties his recycle bin then Alice still has her files in her recycle bin.  However it can be a pain if you are trying to clear space on a hard drive as you can empty the recycle bin on a multi user machine and there are still files taking up space in the recycle bin...

You can control the space available to the recycle bin by right clicking on it and choosing properties.  Sometimes you want to keep a big recycle bin (working with large files) but also try to reduce space used by the bin where possible (Virtual servers with backups of whole VM's, obsessive compulsive sysadmin...).  Each user has their own recycle bin which is great for accountability but the name of each bin is not easy to decipher.

For NTFS partitions the recycle bin is stored in c:\recycler (Note: you have a recycler folder on every partition - for simplicity I'm just going to use c:\recycler in my examples but if you have a D drive you will also have d:\recycler etc...).  This is a system folder so to view it you need to make system files visible (Tools -> System folders -> view -> untick "Hide protected operating system files").  In this folder there will be several folders with long complex names (eg "S-1-8-13-2457591-767657898-480356960-2981" )  This long string of characters is the SID (Security Identifier) which uniquely identifies each user on a computer/domain for security.  You can right click and choose properties on these folders and see the size but if you try to go into a folder that is not yours it appears empty even if full of files.


To determine the user name associated with a SID you can type the following at a command prompt (Replace this sample SID with the one you have of course...):

wmic path win32_useraccount where sid="S-1-8-13-2457591-767657898-480356960-2981" get name

Or if you know the name of a user you can find their SID with this command:

wmic path win32_useraccount where name="bsmith" get sid

Now we can track down who has the big recycle bin so if you have ongoing problems at least you know who to chase.

If you are sure you want to delete a users recycle bin then as long as they are logged out you can just delete their folder under c:\recycler - if they are logged in this file is in use in which case you will have to ask them to do it.

Bitcoin - How and when to backup wallet.dat

Bitcoin is a fascinating subject both from the technical and social viewpoints.  While there is a lot of people online talking about how to use it and whether you should use it, there seems to be far fewer people talking about how the wallet works from a backup perspective.  This seems strange as your wallet contains your money and if you do not understand how it works you might loose your money.

If you don't care about the WHY and just want the answer jump to the bottom of this post.


The first thing to understand is that your wallet does not contain the actual money.  Your wallet contains a lot of public/private key pairs (I'm assuming you understand the basics of public/private key cryptography - if not I'll be writing something up on that soon inspired by the latest portforwardpodcast).  The blockchain contains the list of who has which bitcoins.

Every time you are sent money it is sent to one of your public keys and only your private key is able to send that money on again.  As your bitcoin client downloads each new block it compares it with the keys in your wallet and adds or subtracts the amounts sent to/from your keys.

This is part of the security of Bitcoin as if someone tries to send you bitcoins your client can see if they actually have those bitcoins to send by looking back through the blockchain.  If everything is correct then the transaction will be included in the next block generated which is the first confirmation.  By the time you have 6 confirmations you can be pretty sure the money is yours.

The public/private keys can become used in two ways so your wallet.dat file contains 100 spare keys for future use (you can change this default to anything you want).  A new public/private key pair is automatically generated each time you send or receive bitcoins to help improve the anonymity of bitcoin.  Each new key pair is added to the end of the list and every time a new key pair is needed the oldest spare one is used.

You can see this happening when you receive bitcoins - the client shows your current bitcoin address on its main window.  When you receive some bitcoins a new address from the list of spares will become active and a new address will be generated and added to the end of the spare list.  Since your wallet still contains the old address you can still receive funds sent to it without any problems.


When you send bitcoins a key pair can also be used.  This is because if you have received 10 bitcoins to a single address and you want to send 2 bitcoins the transaction sends all 10.  2 bitcoins go to the person you are paying and the remaining 8 bitcoins are sent back to a new one of your own addresses.  This is all hidden by the client so you do not see these keys.

You can see this happening at http://bitcoincharts.com/bitcoin/ which shows the latest unconfirmed transactions - almost every transaction has 2 outputs.  One will be the money going to its new owner and the other will be the remainder of the money going back to its existing owner on a new address.

You can backup your wallet.dat file, complete several transactions and keep using the new addresses to receive money with no problems.  At some point, probably about 100 transactions (sending and receiving) you will start using key pairs that are not in your backed up wallet.dat file.  If you then loose your wallet you could loose a lot of your bitcoins as the backup will not have valid key pairs to access the money.

What this means for your backup of wallet.dat:

So taking all this into account you should backup your wallet.dat file regularly but it is not necessary to backup after every single transaction.  Your wallet already knows the encryption keys it will use for the next 100 transactions.  Speaking of encryption please encrypt your wallet!  A future bitcoin client is expected to include encryption which should improve things but until then its your money - look after it!

On Linux your wallet.dat file is stored in ~/.bitcoin/

On Windows the location of your wallet depends on your windows version.  For Windows7 (and Vista if you are still suffering that OS) it is in C:\Users\<your user name>\Appdata\Roaming\BitCoin.  For older versions of Windows (eg XP, 2003 etc) it is in C:\Documents and Settings\<your user name>\Application data\BitCoin.

Just close the bitcoin client and copy this file somewhere safe (both "safe if my computer dies" and "Safe from anyone that wants to steal my money"!)  The only file you need to backup is the wallet.dat file - all the other files will be re-created/downloaded if you start the bitcoin client with the wallet.dat file in the bitcoin data directory.

Disclaimer: Everything here is based on my understanding of how things work - I am in no way connected with bitcoin apart from being a user.  The main bitcoin client is still at version 0.3.24 - it is a relatively new program that is likely to change as new issues with the growing bitcoin network emerge and new features are added. 

Yubikey Radius on Premise V3 setup guide

Yubico have just released version 3 of their excellent Radius on premise virtual appliance for authenticating users with a Yubikey as a dual factor authentication.  It now supports multiple Yubico validation servers so is more resilient, has better user management and logging as well as being available in OVF format which should make importing into virtual environments less VMWare specific.

This is a quick guide to how I got it working for my (SBS2003 & Netscreen SSG 140 firewall) VPN's.

Release notes and download links for the appliance and guide can be found here: http://wiki.yubico.com/wiki/index.php/YubiRADIUS_Virtual_Appliance_version_3.0.  As usual with Yubico the guides are clear and take you through the setup step by step.


I downloaded the VMWare image file, extracted and then imported into VMWare using the VMWare Convertor program available from VMWare for importing backups.  Its a very small VM - 8GB hdd, 256MB Ram and 1 virtual CPU.  Imported to VMWare in 3 minutes.

When run the appliance gets an IP address via DHCP so I set this to static by logging on to the console of the VM (user yubikey, pass yubico) then opening a terminal and editing the /etc/network/interfaces file (root default password is also yubico).  Rebooted the machine and logged in from my desktop to the web interface, changed default passwords, logged in again to check.  I tried changing the IP from within Webmin at first but it did not seem to save correctly.

Now it is time to start setting up the Yubikey magic.  There is a seperate Webmin module for Yubikey under the System heading.  Enter your (authentication) domain name and click add.  Under global configuration I entered my API ID and key (generate yours here: https://upgrade.yubico.com/getapikey/). You can also enable auto provisioning (so the first time a Yubikey is used its permanently assigned to that users account.  I don;t like doing this as when I import users I get the whole domain where I really only need a handful of people to be able to connect remotely.  If you only have a few users or want all of your users to be able to connect its a very nice feature to have.

Back on the domain tab I clicked on my domain name then users import.  This is where I had trouble when I set up the previous version of ROP as unless you use it a lot the LDAP syntax can be a bit confusing.

Host: IP address of domain controller
Port: should be 389
LDAP: change to version 3
BaseDN: Where are your users stored in active directory?  Mine looks like this: "OU=SBSUsers,OU=users,OU=MyBusiness,DC=mydomain,DC=com"
UserDN: User with access to connect to active directory (your user account?)  Mine looks like this: "CN=My Name,OU=local,OU=SBSUsers,OU=users,OU=MyBusiness,DC=mydomain,DC=com" - all users in this folder and all subfolders will be imported.
Password: password of the user account specified above
Schedule I left blank (one time import so it will not auto update usernames)
Filter: "(objectClass=person)" - only pull through user accounts
Notes: I left blank
Login Name Identifier: "sAMAccountName"

Hit "Import Users" and you should get a message reporting success.  Go back to the users tab and you should have a long list of peoples accounts from Active Directory.  From here you can manually add a yubikey to users accounts.

Next I need to tell the ROP server to accept queries from my firewall.  This is done on the configuration tab for the domain and just needs the firewalls IP address and shared secret.  One very nice new feature of ROP3 is the RadTest tab which lets you test an account is working.  Getting failures on the firewall can be a pain because its not always obvious where the issue lies - this lets you eliminate the ROP side of things easily and quickly as if it works here it must be the firewall with issues.  However there is one point that is important:   IN ORDER TO USE THE BUILT IN RadTest TAB YOU FIRST HAVE TO ADD THE LOCAL 127.0.0.1 IP TO THE LIST OF ALLOWED CLIENTS UNDER THE DOMAIN->CONFIGURATION TAB!  I lost some hair trying to work out why it was not working - I assumed that the new feature to test if things were working would be allowed through by default.  My bad - very obvious mistake of mine with hindsight!  If the RadTest seems to do nothing keep waiting - its not too obvious it is doing something if it is hitting a timeout.

Once tested you should be able to point your systems at its IP address (Radius port 1812, accounting port 1813) and start authenticating your domain users with Yubikeys.  At some point I'll document how I setup the Netscreen SSG 140 side of this to give my users dual factor VPN access to my network.  If that would be handy to anyone drop me a comment and I'll move it up my list of things to post.

[UPDATE 12 March 2012: Done! Click here for my guide on setting up a dual factor VPN on Netscreen firewalls]

Connect to a network device without knowing its IP address

A handy tip from Linux Format (LXF147).  If you have an appliance which is turned on but you do not know its IP address you can still connect over the network using the arp table.

On pretty much any appliance there will be a sticker with model number, version etc.  Most appliances will also show their mac address on these stickers and you can use this to connect over the network.
To show the current arp table which might already contain the device run

sudo arp -n

If its not shown then you can assign a temporary IP address for use from your computer with:

sudo arp -s <IP ADdress> <MAC address>

This is a lot quicker than starting something like nmap and scanning whole network ranges to try and spot the IP address you need.  With this you should be able to connect to that new network storage device you just plugged in and browse its admin interface to discover and/or set its propper IP address.

PortForwardPodcast VMWare Notes

Recently I was invited on to the excellent PortForwardPodcast to talk about VMWare and how it works for small businesses.  Please check out their site for several other excellent podcasts.  I've copied my notes for the show below so if you came here following that podcast you might find a bit more detail below.  Or check my other posts on this site as I have made notes several times on VMWare as I have been learning to use it and deploying it.

Veeam VMWare network restore speed

Whilst most of VMWare is very fast and efficient copying files in and out of the datastore is depressingly slow - you are lucky to get 10 MB/s even with fast hardware and gigabit network, I normally get closer to 5 MB/s.  There is a trick you can use with Veeam restores over the network to vastly improve this speed, something similar should work if you are using shared storage but I can't test this myself.

The problem is basically the slow network performance when copying files to or from the datastore over the network.  There are a lot of people talking about this online and it has been an issue with VMWare since at least version 3.5 (4.1 made some small improvements).  At 5MB/s a large VM  can take ages to copy - especially as it transfers the full image over the network.  So if you have a VM with a "thin" hard disk format, 200 GB in size but with only 10GB of data it will take 10GB on the datastore.  When you try to copy it to your desktop it will transfer 200GB over the network.  The code that deals with migrating datastores, storage vMotion etc is all really fast so people with higher end setups will not use this feature much.  Also if you have a SAN you can just upload direct to the SAN then connect it to VMWare - not possible if you are using local storage...


This faster code is the way to get big VM's onto ESXi quickly using Veeam.  First you need to do an "Instant Recovery".  This sets up the VM on the destination ESXi host but also shares a folder from the Veeam server containing the backed up image.  Restoring this instant recovery takes seconds regardless of the size of the VM.  However the files themselves are still stored on your backup server.  If you were to turn on this instantly recovered VM it would be running from files over the network - probably a bit slow and not what you really want to do long term.  However if instead you right click on the VM in vSphere you can choose to migrate - follow the wizard and tell it to change the datastore.  Moving the files from the temporary backup datastore to your main datastore like this runs as fast as your hardware supports - probably at least 20MB/s even on fairly normal servers as long as you have GB network cards in use.

Hopefully VMWare will fix this soon as it takes a bit of googling to find out why restores take so long with Veeam and find  a workaround - I'm sure many people just give up.  This same problem makes backing up a VM from the free ESXi hypervisor a very slow process, which might be putting people off from buying the program.