The latest jailbreak, Spirit, has been released by @comex and enables one to easily jailbreak any iPod/iPhone (beta for iPad) via a single click. For the doubters and undecided, this includes 'all' firmwares (up to 3.1.3) as well as any model: 2G, 3G, MC models, 8GB, 32GB, 64GB, etc. I've successfully jailbroken my new 32GB iPod 3G which had the 3.1.3 firmware pre-installed. The 3.1.3 firmware and MC models were previously difficult and in the case of MC models, impossible to jailbreak.
Download Spirit at http://spiritjb.com and have fun.
Troubleshooting: 1) If you encounter error code c0000005 on Vista or Windows 7, simply set the Spirit EXE to run as 'Windows 98 / Windows ME' compatibility mode by right-clicking the spirit.exe file, select Properties and choose the Compatability tab. 2) If your iPod/iPhone gets stuck at the Apple logo after rebooting, hold down both the sleep and home buttons until the iPod shuts down, then boot it back up via the sleep button.
Essential Jailbreak Apps
Microsoft included a sweet little utility in Windows 7 which conglomerates all the too often difficult to find utilities and settings into one place. It's referred to as GodMode and is built into the OS, although not available initially. It acts as sort of a control panel applet I guess you could call it.
To enable this nifty feature, simply create a new folder and rename it to:
GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
Once you rename it the folder icon will change and you can open it and make all those customizations you've been wanting to, but haven't had the motivation or energy to find.
Rebuilding 8 Windows 2003 production web servers is a fun task. It's good, wholesome family fun. In order to speed up the process, Microsoft's Sysprep makes it much simpler to clone Windows installations. Of course, it helps to use the same server types and in our case the affected systems are 8 HP BL20P Blade servers housed in a single enclosure. With a full Windows 2003 R2 install with patches and all, it's a simple process to run Sysprep with the shutdown option, pull the drive, replace with a blank for the controller to rebuild the array, then pop the cloned Sysprep drive into another Blade server.
But, what if you want the second partition of an array to have E as its drive letter instead of D? Due to the Blade's lack of any CD/DVD drive, Windows automatically uses D as its second drive letter. Well, it's a somewhat simple task to accomplish, but if you follow Microsoft's own instructions, you won't get no love.
By following Microsoft's instructions here http://support.microsoft.com/kb/928543, you will get most of the way, but wind up with the good ol' letter D for the second partition:
To automatically assign a drive letter, first create the DiskPart script, and then run the Sysprep tool.
The following script (Script.txt) is used to assign the drive letter of the second partition to drive 'X'. This script assumes that you have divided the hard disk that connects to the computer into two partitions.
select disk 0
select partition 2
remove noerr
assign letter=X noerr
Seems simple enough, eh? Well, after Sysprepping the same drive about 5 times, I eventually discovered that the Cmdlines.txt file requires double QUOTES around all commands! So, step 2 above should have read:
So, here is my improved, simplified rewrite:
The following script is used to assign the drive letter of the second partition to drive 'X'. Change 'X' to the drive letter you want. This script assumes that you have divided the hard disk or array into two partitions. Copy the following text exactly, paste it into a txt file named Script.txt and save it to the folder C:\Sysprep\OPTION
select disk 0
select partition 2
remove noerr
assign letter=X noerr
Copy the following text exactly, paste it into a txt file named Cmdlines.txt and save it to the folder C:\Sysprep\i386\$OEM$
[COMMANDS]
"DISKPART /s C:\Sysprep\OPTION\Script.txt"
Add the following line to the [Unattended] section of the Sysprep.inf file (This should already exist if you generated a full unattended sysprep.ini):
InstallFilesPath=C:\Sysprep\i386
Run the Sysprep.exe file.
BAM! It werx! It's funny how the lack of two simple little quotes can cause so much pain.
Cisco has finally relented and provided us with a 64-bit VPN client supporting (well, beta support) Vista and Win7 x64. Although they aren't going to provide a XP x64 client, this beta is a welcome and long overdue blessing. Functionality on Win7 x64 is stable (so far as I can tell), hardware token (eToken, etc.) integration works great and the install doesn't require a reboot.
Get your copy on Cisco's site via your SMARTnet login here: http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=281940730 under the 5.BETA category.
In order to export one of our Microsoft virtual machines to XVA format for Xenserver (something else I may post about), I had to completely take down the virtual server itself... a MS Virtual Server 2005 instance. This needed to be done simply to install Microsoft's VHDMount application included only with the full 40MB install of Virtual Server 2005 R2 SP1. Sure, I could have simply taken down the Virtual Server service, installed the VHDMount app alone and gone on with my life, but I was feeling rather daring and decided to upgrade to the latest version.
After having upgraded to R2 SP1 and thus acquiring the one thing I needed to do the export, VHDMount, I proceeded with my bidness exporting a VMC to XVA using Citrix's nifty V2XVA cmdline utility. I guess it went OK. No errors and it exported both volumes on the VM, but I haven't imported into Xenserver yet, so success is hopefully to come. However, once the conversion completed, I rebooted to consummate the union... er, upgrade of the virtual server.
To my surprise the Administration Website worked! Not really. I had a nice, welcoming "Could not connect to Virtual Server. Access was denied." message. The first thing I thought was, duh, permissions. Setting Everyone with 'read and execute' privileges on the entire VirtualServer folder did nothing. Next, I disabled anonymous access to the IIS website, hoping to get a login prompt. No change. Then I created a brand new IIS website, applied all the settings and... no love. Soon after I found Microsoft's little KB 891609 article. My heart raced as I opened the 'virtual server' COM object, clicked on the Security tab and found... that... well, the suggested permissions were already set. Rats. I haven't mentioned yet that I did do one more reboot of the server after all these changes.
So, I got desperate, being that I was about 4 hours into my Sunday working on an annoying issue. Remembering my disabling of anonymous access to the site, I went in and re-enabled this setting and did an iisreset, ready to give up and take a nap. Eureka! Refreshing the Admin Website presented me with my virtual servers once again and booted them like a champ.
Hopefully this will help anyone out there with a similar issue. Before you pull the rest of your hair out, simply disable anonymous access, iisreset, then re-enable and iisreset. Stopping and restarting the 'virtual server' website may also do the trick.
In order to export one of our Microsoft virtual machines to XVA format for Xenserver (something else I may post about), I had to completely take down the virtual server itself... a MS Virtual Server 2005 instance. This needed to be done simply to install Microsoft's VHDMount application included only with the full 40MB install of Virtual Server 2005 R2 SP1. Sure, I could have simply taken down the Virtual Server service, installed the VHDMount app alone and gone on with my life, but I was feeling rather daring and decided to upgrade to the latest version.
After having upgraded to R2 SP1 and thus acquiring the one thing I needed to do the export, VHDMount, I proceeded with my bidness exporting a VMC to XVA using Citrix's nifty V2XVA cmdline utility. I guess it went OK. No errors and it exported both volumes on the VM, but I haven't imported into Xenserver yet, so success is hopefully to come. However, once the conversion completed, I rebooted to consummate the union... er, upgrade of the virtual server.
To my surprise the Administration Website worked! Not really. I had a nice, welcoming "Could not connect to Virtual Server. Access was denied." message. The first thing I thought was, duh, permissions. Setting Everyone with 'read and execute' privileges on the entire VirtualServer folder did nothing. Next, I disabled anonymous access to the IIS website, hoping to get a login prompt. No change. Then I created a brand new IIS website, applied all the settings and... no love. Soon after I found Microsoft's little KB 891609 article. My heart raced as I opened the 'virtual server' COM object, clicked on the Security tab and found... that... well, the suggested permissions were already set. Rats. I haven't mentioned yet that I did do one more reboot of the server after all these changes.
So, I got desperate, being that I was about 4 hours into my Sunday working on an annoying issue. Remembering my disabling of anonymous access to the site, I went in and re-enabled this setting and did an iisreset, ready to give up and take a nap. Eureka! Refreshing the Admin Website presented me with my virtual servers once again and booted them like a champ.
Hopefully this will help anyone out there with a similar issue. Before you pull the rest of your hair out, simply disable anonymous access, iisreset, then re-enable and iisreset. Stopping and restarting the 'virtual server' website may also do the trick.
