WEP is the redheaded stepchild of WPA & WPA2. For quite some time it has been very easy for someone with limited Google searching skills to crack. In the video below the presenter shows you how easy it is to crack WEP.
View full article »
Latest Entries »

Rain Gutter Cable Tray
This is the most ingenious use of a rain gutter for something other that shunting off rain I have ever seen. My office is currently in cable hell and this lil trick just might be the thing to fix it.
Check it out over at Flickr.
With the recent update to the IMF signatures for Exchange 2003 I got caught in a never ending circle of installation prompts. The new update would install, then last months update would ask to install and so on and so on. After realizing what was going on I went in search of answers. The 1st thing to try was to reset the Windows Update Cache. It can be done by plopping the code below in to a bat file and running it on the offending server.
net stop bits
net stop wuauserv
regsvr32 /u wuaueng.dll /s
del /f /s /q %windir%\SoftwareDistribution\*.*
del /f /s /q %windir%\windowsupdate.log
regsvr32 wuaueng.dll /s
net start bits
net start wuauserv
wuauclt.exe /resetauthorization /detectnow
This did not solve the issue for me. I turned out that my WSUS server did not mark the old IMF update as declined. Once the old update’s status was changed to declined the update cycle was stopped dead in its tracks.
Last night I moved my PRTG virtual machine to my newly installed ESXi server. The move went well, but when I went to boot up the PRTG VM the service wouldn’t start. PRTG was nice enough to tell me that I had another copy of the service running on the network and even gave me the command to find the PC it was running on.
Turns out it was running on an old monitoring PC I had used years before that was still powered on. Since I still use it for a couple of other monitoring apps I couldn’t just turn it off. As a temp fix I stopped the service and set it to disabled. Now the PRTG VM started up and began collecting data once again.
As the PRTG uninstaller did not remove the PRTG service from the old monitoring PC I still needed a way to pitch it even though I had disabled it. A quick search turned up a couple of options, the easy way and the slightly more difficult way.
The Easy Way:
sc delete “service_name”
In my case the command was:
sc delete PRTGService
The Slightly More Difficult Way:
**Dislaimer: This process involves working in the Windows Registry. Before deleting any file please make a backup in case of borking your system.
Run Regedit Find the registry entry “HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services” Look for the service there and delete it.
I came back from my extended leave to find that my workstations and servers had not checked into the WSUS server for months. After a bit of detective work the issue came down to the SelfUpdate virtual directory in IIS was missing. The Microsoft help page details how to fix the issue but wasn’t completely helpful. More on that later.
Here is what I did to get my clients checking in again.
Check the folder permissions on the SelfUpdate directory, located at C:\Program Files\Update Service\SelfUpdate. Make sure the permissions like this;
| Group | Permissions |
| Administrators | Full Control |
| System | Full Control |
| Domain/Users or Local/Users | Read&Execute, Read, List Folders |
| IUSR_ComputerName | Read&Execute, Read, List Folders |
In my case the IUSR_ComputerName permission was missing.
After adding the correct permissions I looked for the re-installation msi, Selfupdate.msi. The only problem is that the SelfUpdate re-installation msi was not found on my WSUS server. Turns out in the recent WSUS update to 3.1 this installer can become corrupted and not installed on the server.
To get the Virtual Directory back I would have to install it by hand. Here are the settings you need to create it;
Open Internet Information Services (IIS) Manager. Right click on the “Default Web Site” and choose;
- New
- Virtual Directory…
- It started the VD Creation Wizard
- Alias = SelfUpdate
- Path = C:\Program Files\Update Services\SelfUpdate
- Finish the wizard.
- Right click on the newly SelfUpdate and choose Permissions.
- I added “Authenticated Users” and gave them the default rights:
- Read & Execute
- List Folder Contents
- Read
After completing these steps I ran “wuauclt /detectnow” on each of my servers. I left the workstations to check in on their own.
Within 12 hours the number of missing clients had gone from nearly 200 to less than 50. Once everyone logs in on Monday morning this number should dwindle to nothing.
I have been using Diskeeper’s products for 6 years and have commented on them before. It is my opinion that their products are slipping.
But another review of their products is not the reason for this post. I received a Christmas card from them this year and inside of it was a quote from L. Ron Hubbard, of Scientology fame. I thought it was quite odd to feature a quote from him inside a Xmas card and noted it on Twitter, saying something along the lines of “seriously thinking of ending my business with Diskeeper”.
Not long after a had a comment on said Tweet which informed me of a legal dispute with a former employee suing Diskeeper for forcing Scientology down his throat.
I really cannot stand the integration of church/religion and state or your place of employment. I do not care that it was a quote from the writer of this classic pile of crap or if it had been a quote from the Pope, or the Dalai Lama. Leave your preaching to your personal life.
So this ends my business relationship with Diskeeper. Time to find a new application to keep my disks unfragmented. Note: On home machines I like Defraggler
The Windows 7 Beta launch yesterday had its share of problems and the Windows 7 team took notice. They have extended the beta download time and increased the number of keys beyond the 2.5 million initially slated for download.
I tried for most of Friday to get my keys but was unable to get past the green circle of death. Today the process was painless and carefree.
I haven’t had the time to install it yet, but look forward to doing so and seeing if the hype meets expectations.

A user reported an issue with her printer this afternoon. Whenever she tried to print it locked up her PC. I tried all my usual tricks to hack out the offending job, but nothing I tried was working. The print spooler would crash seconds after starting. This error kept taunting me:
“Spoolsv.exe – Application Error”
“The instruction at “0x77fcc2c0″ referenced memory at “0×00000000″.
“The memory could not be written.”
I popped out my trusty Troubleshooting Swiss Army Knife (read: Google) and quickly had another tool to fight the tenacious spooler.
It turns out the most common cause of the error is an abundance of .SHD and .SPL files in the spool directory. These files are created by the spooler to save the spooled data of a print job. The .SPL file comprises drawing commands and the .SHD file comprises job settings information of the print job.
To fix spoolsv.exe application error, you will have to remove these files from the system. To do this, perform the following steps on your Windows XP computer:
- Open Control Panel, select Performance and Maintenance, select Administrative Tools and then select the Services option.
- In the Services management console, locate the Spooler services, right-click on it and select Stop.
- Next, open the C:\Windows\System32\Spool\Printers folder. (Here, we are assuming that your Windows is installed in the default C:\Windows folder)
- Delete all the .SHD and SPL files from this folder.
- Next, open the TMP folder and delete all old and unused files from this folder.
- Finally, restart the Spooler service from the Services management console.
Just like that the users printer problems disappeared.
WSS 3.0 uses Microsoft SQL Embedded Edition (MSEE) for its data store. When MSEE is installed, the data files are installed to your C: drive by default. Since you do not want to have a file on your system drive that can grow exponentially, you need to move it to another drive. Here is how you do it.
Note: While completing this process your WSS site will be offline to your users.
- Shutdown all Windows Sharepoint services & IIS Admin service: This will ensure that there are no locks on the files you need to move.
- Open a cmd prompt and cd to C:\Program Files\Microsoft SQL Server\90\Tools\binn
- Enter sqlcmd -S \\.\pipe\mssql$microsoft##ssee\sql\query -E: This starts the Microsoft SQL Server 2005 Command Line Query Utility
- Enter the following commands to view the available databases & hit Enter after each:
- SELECT name from sysdatabases
- GO
- SharePoint_Config_c464b7ce-59ef-4820-9f75-f46a0937c08e
- SharePoint_AdminContent_451452bf-9dc0-40c9-be18-14f14bc23007
- WSS_Search_NETSERVER_86a140c5958d4a5d97c8c2cbee745424
- WSS_Content
- Enter the following commands & hit Enter after each line. Repeat for each database.
- EXEC sp_detach_db @dbname = ‘Content_Database_name’
- GO
- Move the databases to their new location. They can be found in C:\Windows\SSQL\Data\
.mdf and_log.ldf - After the files have been moved run the following commands (Make sure to change the itialic sections to your specifics):
- EXEC sp_attach_db @dbname = ‘Content_Database_name‘, @filename1 = ‘drive:\path\Data\
.mdf’ , @filename2 = ‘drive:\path\Data \_log.ldf’ - Go
- Repeat step 7 for each database you moved.
- Restart IIS Admin services and all Windows Sharepoint services
- Ensure your Sharepoint site is working
You should see a number of DBs, move the following 4 databases (GUID’s may be different):
If this is done before you build your site it will take no time at all to move the DBs to the new location.
Three more videos of our little monster.





