So, it just so happens that I left Godaddy a few months ago just because I finally got sick of their terrible pricing and misleading terms. Not only that but their site is intentionally obtuse, they try to cleverly pad sales with extras and make it difficult to disable auto-renewals. There was a time when they were THE go-to domain registrar but those days are long gone. Better pricing alone should be incentive to switch registrars.

Coincidentally, GoDaddy’s recent blatant and arrogant support of the federal internet censorship bill – Stop Online Piracy Act, “SOPA” caused the outrage of the internets who called for a boycott. GoDaddy has lost tens of thousands of domains already and has since reversed their position on SOPA as a result, but the boycott will proceed regardless. Namecheap.com, a far superior and less expensive registrar, is offering a transfer special in honor of the boycott. Coupon code: SOPASUCKS

If you have domains to renew anyway or need a reason to get away from godaddy, there you go…

I’m fairly new to Droid, ~5 months now, and was formerly a corporate BlackBerry user for years. The BB was always company paid so while short on the user experience it was still a no-brainer and provided the basics, largely thanks to Google apps. Once my BB use came to an end (and my days of production support as well) not going iPhone was also a no-brainer. As an “in the weeds” technologist, Android suits me perfectly! ROMs, recovery, kernels, radios, overlays, launchers…every piece of Android is completed customizable and I love it. Unlike Apple’s limited walled garden, Android is the wild badlands so you do need to be careful. There is no Windows Update equivalent in Android where every device gets firmware updates direct from Google. This is handled by each phone OEM in cooperation with the wireless carrier. Because of this, Android phones are not always kept up to date or even at the same build of the OS! Most users are none-the-wiser. Apple’s method is much better ensuring that all iPhones stay current. Android, following the Windows distribution model, is also free to be stuffed full of system-slowing bloatware by the OEMs and carriers that customize the OS for each device. This is not allowed in the Apple world (kudos). If you don’t mind a little nuts and bolts tinkering, you can run whatever version of Android you like, debloated, rooted, deodexed, and are free to change what you like for an incredible user experience. There is a ton of information out there all over the place so this post will serve to consolidate the pertinent research and hands-on I did for my devices.

I have 2 very different but individually awesome devices in my clutches: The Samsung Charge and the Motorola Droid X (DX), both on the Verizon network.

The Charge is newer and one of the first LTE phones on the Verizon network. It currently does not have any officially released OTA version of Gingerbread, although the latest 2.3.6 leak suggests it’s coming soon. The DX has been running Gingerbread for a few months now. While the DX is 3G only, it is still great performer and a stalwart among Droid enthusiasts.

Droid Charge

The Charge comes with Froyo (Android 2.2), the TouchWiz overlay, and plenty of bloat courtesy of Verizon. Battery life was acceptable, not great, in stock form lasting no more than 15-20 hours. The worst part about the bloat is that they’ve engineered it into the OS so that it’s always running. You can kill it with a task manager but it will just come back. So that by itself is a heavy justification to root and/ or run a custom ROM or app with freeze ability. Even with no root access a number of things can be changed and customized. The launcher is usually the first thing out the door as it controls the look and feel of the OS. Themes, icons, fonts, transitions…all of these things can be changed. My favorite launcher at the moment is the Go Launcher EX. Go adds some really neat things like 3 additional pages of bottom screen shortcuts, a ton of themes, widgets, and the ability to customize every aspect of whatever theme you choose. Go also offers some other good stock app replacements such as Go SMS Pro and Go Contacts/ Dialer. This has got the be the coolest aspect of Android. You don’t like the keyboard or dialer? No problem, just replace them. Before changing the launcher, you will also need to install a home switcher app such as home manager. Here is my home screen using Go Launcher EX with a glass theme and Sense-style clock.

While changing the launcher can definitely improve the experience provided by the OEM it does not deal with the bloat slowing down the phone. For the more adventurous the stock ROM can be completely replaced. There are a few options out there including leaked builds from the OEM/carrier and third parties such as GummyCharged. The leaked builds come rooted and bloated or not. Some folks prefer to run the bloated ROMs and use apps like Titanium Backup Pro to freeze the offending bloat. I am opting to run rooted and debloated ROMs as I’m not concerned about OTA updates at this point. Other popular choices are still not yet available on this platform, namely CyanogenMod and MIUI.

Each OEM has its own unique toolsets for working with the hardware. Samsung has an official flashing utility but there is also a third party utility called Odin that is used for flashing. Unlike the Motorola, flashing the Charge with a new ROM is as easy as:

1. Load the Samsung drivers on your Windows7 PC and launch Odin
2. Put the phone is download mode by:
   • Turning off phone
   • Remove SIM card
   • Hold volume down, press power firmly for 1 second and release
   • Once in DL mode you will see this screen:
   • 
3. Plug phone into USB on PC (preferably the rear of PC)
4. Push the new ROM to the phone via Odin using the “PDA” setting (very important!).

That’s it! No need to run rooting apps, boot to recovery or run console commands. When you reboot the phone after the flash it comes back up rooted, debloated, and running all the latest including radios and kernels. No data on the SD card is affected at all. Odin can also be used if you messed up and need to return your phone to a stock ROM. I strongly recommend that you remove the SIM card before flashing! There have been some reports of problems when flashing with the SIM in. Detailed step-by-step on using Odin here.

Here is my phone running the (hopefully) final official Charge Gingerbread build, but rooted and debloated.

So far the new build is excellent. I haven’t observed any bugs or glitches at all. Zero bloat and my battery life has increased to 24+ hours now. We don’t know about Ice Cream Sandwich yet (Android 4) for this device but that will be my next upgrade, unless MIUI or another official GB leak surfaces of course…

Droid X

The DX has been around for a little while now but is still a solid performer and more than capable of running the latest software. It has its own batch of stock bloat and depending on how much stuff is running can lag a bit. The biggest single thing missing from the DX in stock form is the pull down toggles that the Charge has. I’ll fix that here in a moment however.

Just like the Samsung devices, Motorolas have their own tools and drivers. The Motorola flashing utility is RSD Lite which is used to revert to a stock ROM, a process called “SBF”-ing. Because my DX received an OTA upgrade to Gingerbread I had to SBF it back to stock before I could root and apply a custom ROM. There are definitely a few more steps to achieve the same end result on this device. The following steps were required to apply a custom ROM and recovery on my DX:

1. Prepare to sbf back to stock froyo
   • Put sbf file in root of C:\ on PC
   • Connect phone to usb, reboot into download mode
   • Hold camera button, vol -, hold power for 1 sec to enter DL mode
2. Use RSD Lite to load sbf file
   • Once in DL mode select sbf file, click start
   • You may have to manually reboot and put phone back in DL mode to finish
   • 
3. Boot to stock recovery (see section below for how)
   • Select Wipe/ factory reset
   • Reboot
4. Get root
   • Install Z4Root, reboot, then run it, select permanent root
5. Load Droid2 bootloader
   • Load ClockworkMod Droid2 bootstrap from market (cannot get into CWM recovery without this!)
6. Load Rom Manager from market
   • Flash CWM Recovery from Rom Manager
7. Reboot to recovery (which should now be CWM)
   • Factory wipe/ backup if you want
   • Load zip of custom ROM you want to load
   • Reboot

Subsequent ROM loads should be much simpler and can be done easily from recovery with the files stored on the SD card. I was going to load an official DX ROM similar to what I did on the Charge until I found the magic that is MIUI, recently made available for the DX. MIUI is a custom ROM that is not only beautiful but highly customizable and adds nearly every feature one could want coming from a stock Motorola build. Lock screens that allow you to go right into phone or SMS apps, pull downs with toggles, even data monitoring/ alerting and application level firewalling where you can prevent certain apps from using 3G or wifi. MIUI even has the much coveted “CRT effect” when you press power to lock the phone. Very cool! If they ever make this available for the Charge I will definitely give it a go.

Recovery Mode

/recovery in the Android file system contains some basic maintenance tools that can be booted into outside of the OS. Like all other Android components this stock recovery can be replaced with an upgraded aftermarket version. Most people who root and tweak their phones prefer to run the ClockWorkMod (CWM) Recovery. For the Charge, just like the core OS ROM, CWM can be flashed on the device using Odin. The process is a bit more involved on the DX as I outlined before because the bootloader has to be replaced first. With CWM ROMs can be loaded, backed up and restored directly from recovery.

To boot to recovery on the Charge:

• Turn phone off
• Hold volume up, Home, and Power buttons
• Samsung logo will come up and disappear
• When Samsung logo comes up for a second time, let go of all buttons

Controls:

• volume up/down = up/down
• Power = enter

To boot to recovery on DX:

• Turn phone off
• Hold Home button and press Power until the Motorola logo appears
• Release Power and continue to hold Home until an exclamation appears
• Release Home and press the Search button once.

Controls:

• volume up/down = up/down
• Camera button = enter

Apps

Running rooted there are a few apps that you just must have. Some builds come with a few of these but some do not (MIUI).

Superuser – grants SU rights to applications on your phone that need it, must have this!

ROM Manager – This currently does not work for the Charge and many prefer not to use it, but it’s an easy way to flash CWM recovery and manage ROMs from within the OS.

Busybox – Linux toolset installer, some other apps like Titanium Backup need this.

Droid 2 Recovery Bootstrap – (for DX) allows you to boot into CWM.

Titanium Backup – Free and Pro (donate) version. Allows you to backup/restore apps and relating data, freeze/thaw apps, as well as a number of other things. This is a VERY powerful utility.

Swiftkey X – This is my favorite keyboard right now and you don’t have to be rooted to run it. Great customizability and incredible for speed typing with deep learning capabilities for predictive text.

Cases

After spending hundreds on these phones, I opted to protect my investment from the potential drop or day-to-day unprotected wear. After doing quite a bit of research I narrowed down my selection to Otterbox and Incipio. Both are very well regarded in terms of quality and protection. I ultimately went with the Incipio SILICRYLIC on both phones which is a 2-part soft layer in hard shell case that protects the phones very well. The fit, finish, and quality of materials is exceptional. The minimal bulk added to the phone is completely worth it. The phone still fits in the pocket nicely.

So far I’m really enjoying my stay in Droid country and after being with ATT for nearly a decade, Verizon is a breath of fresh air. I have built and customized my own PCs for many years so it makes sense to have similar control on my smart phones. Rooting doesn’t have to be a scary thing if you are very careful and do your research before pulling the trigger. Everything documented in this post is to be used at your own risk. I am not responsible if something goes wrong and you brick your phone (most of which are recoverable anyway). All of the files that I discussed but did not provide direct links to can be found, you just need to dig a little.

Resources:

http://www.mydroidworld.com

http://www.xda-developers.com/

http://www.addictivetips.com

http://www.droidforums.net

I use the Klipsch ProMedia 2.1 speaker setup on my home PC and for awhile now I’ve been getting audible cracking and static noise when adjusting the volume. This fix also applies to other household devices that use potentiometers (pots) so hopefully you will find this useful.

Basically, the pot needs to be cleaned and lubricated as it is transferring noise into the audio system. The first thing to do is head over to Home Depot and grab a small can of CRC 2-26, which for me was less than $3. This formula is both a cleaner and a lubricant which is important because some contact cleaners have no lubricant. The CRC worked fine for me but if you want the Cadillac of contact cleaners check out DeoxIT which runs ~$15/ can.

To get started you need to expose the pot by removing the case or covering of the volume control. The external knob connects to the metal stem of the pot which will look something like this:

Spray a small amount of fluid on the stem of the pot and the threads. Turn the stem back and forth many times to work the fluid in, you should notice the resistance lessen while turning. Let the fluid dry and test the volume control before you button everything back together. I followed this procedure on my Klipsch set which now turns smoother than before and the scratchy static is gone.

New with vSphere5 is an all new SUSE Linux-based (SLES11) virtual appliance to optionally run vCenter. The Windows-based counterpart is still available, of course. DB2 provides the embedded backend of the vCenter vApp with remote data support provided for the Oracle DBMS only, no SQL server (yet).  Despite the list of limits with this version (outlined below), the vCenter vApp is a very compelling option that introduces great simplicity and cost savings to your overall vSphere solution. The SUSE and DB2 licenses come free of charge but you will still need a vCenter license so you can save on the Windows Server and potentially SQL Server licenses. The embedded DB2 database can support up to 400 hosts or 4000 VMs provided you give the vApp enough RAM. There are currently a few important limitations of the vApp, as identified by Duncan Epping of VMware, that could make it a deal breaker for you:

• No Update Manager
• No Linked-Mode
• No support for the VSA (vSphere Storage Appliance)
• Only support for Oracle as the external database
• No support for vCenter Heartbeat

To get started you will need 3 files: the system VMDK, the data VMDK, and the OVF file. These can be downloaded from VMware under the vSphere5 components for vCenter.

Connect to an ESXi host directly via the vSphere Client and deploy the OVF template.

Review the details of the vApp then define the name and location.

Next select the disk format. You will notice that vSphere 5 has some new provisioning options here for thick disks: Lazy and Eager zeroed. Lazy zeroed has all space allocated at the time of creation, but each block is zeroed only on the first write. This reduces creation time but also reduces performance of blocks only the first time they are written to. Eager zeroed has all space allocated and zeroed at the time of creation. This increases disk creation time but also increases performance of all block writes. The eager method is more of a “true” thick provisioning in the classic sense while lazy is more of a hybrid of thick and thin.

Once all selections are made, you are off to the races. Deployment can take several minutes to complete.

By default the vCenter vApp is configured with 8GB vRAM and 2 single core vCPUs, the configuration of which is another new feature in vSphere5.

Once the VM is powered on you will come to the following console screen that details how to connect. Initial vCenter configuration is done via web browser on port 5480.

Once connected via web browser, the initial login is root\vmware.

Before you get started, accept the EULA and check for any updates to the appliance via the update tab.

There are a few additional configuration items to address before vCenter will be usable. The first of which is defining the database settings. You can choose to use the embedded DB2 database or specify an external Oracle server. Make your selection and save the settings.

Next, select the inventory size you intend to work with. As you can see in the following screenshot, a setting of “large” equates to 400 hosts or 4000 VMs and will require a minimum of 17GB of vRAM for vCenter.

With those items checked, you should now be able to start the vCenter service.

Before you leave the web configurator, it might be prudent to set a static IP and configure Active Directory integration as well. Now you should be able to connect to vCenter via the vSphere client. vCenter itself is still the familiar interface that you would expect. Functionally, besides the few missing items, there is no difference between this Linux-based vApp and its Windows counterpart. 3rd-party plugin/ addon support may vary in the vApp model.

The vApp performance overall is quite good and there is no issue moving it between hosts in its cluster. Assuming feature integration continues and the gap between this appliance and the Windows solution is narrowed, it makes sense that the vApp may one day be the only offering for vCenter. There are quite a few other things that must happen first, however, namely the View component integration requirements. There is still an awful lot in VMware’s overall product offering that relies on Windows and that OS’ integrated technologies. I definitely recommend that you give the vCenter vApp a spin and see if it is a good fit for your organization.

As we all know, vSphere5 is here and many of us are already running it in production and in our labs. I’m sure VMware wrestled with the idea of half-stepping this to rev 4.5 but ultimately decided that there was enough different it deserved a major release. Feature-wise there are only a few net new options and only at the Enterprise Plus level, but the maximum capabilities of the hypervisor have grown significantly in most key areas. ESX and its beloved console is gone now, of course, leaving ESXi as the only option. vCenter 5 is available as a Linux-based virtual appliance which many have been waiting for. The biggest change to vSphere is the licensing model which, if you follow VMware’s logic, does make some sense. So while vSphere5 does now include a vRAM entitlement, it no longer has physical host CPU or RAM limits which were imposed in previous versions. That said, I do prefer a model that leverages tiered upgrades based on feature sets, not how much of your host you intend to use. As a result, many customers may be pushed into buying Enterprise or Enterprise Plus just so they can use the RAM they have installed!

Based on the new model, vRAM entitlements are per physical CPU which equals 1 license. Standard edition will net you 32GB per physical CPU, so 64GB total in your average dual CPU server. Any more than that and you’ll be looking at a higher license tier. The interesting aspect of the new vRAM entitlements is that they pool across ESXi servers managed by the same vCenter server (or linked mode). You still need a license per physical CPU no matter what, but you might just end up with an entitlement reserve that can, in part, be used toward future servers with denser DIMMs.

In the following example I have 3 dual CPU ESXi hosts, 2 with 96GB RAM, 1 with 192GB RAM. The minimum license level I can buy (if I want to use all my RAM) is Enterprise at 2 licenses per host. This gives me a 64GB per CPU entitlement or 128GB total per host. Because my first 2 hosts only have 96GB, this leaves a spare 32GB per server. Just enough to entitle server #3 with 192GB.

Another point of interest is that there is a maximum penalty of 96GB that counts against a vRAM entitlement. So VMs configured with more than 96GB vRAM would only deplete the entitlement by the maximum amount: 96GB. If you’re planning to run vSphere for the purposes of VDI then there is a special Desktop Edition that changes the rules completely. No vRAM entitlements, Enterprise Plus feature set, and you can run all VDI related infrastructure under the same license model (SQL, XenDesktop components, View components, etc). Below is a breakdown of the different editions.

vSphere Standard, Enterprise, Enterprise Plus

• Each CPU license comes with a vRAM entitlement. These entitlements are pooled across all vSphere servers managed by vCenter (single or linked mode).
• vRAM entitlements are pooled by vSphere edition. Mixed editions in same vCenter will create multiple pools.
• No physical CPU core or RAM limits (Vi4 was limited to 12 cores max)
• Limits are honor-system based, not software limited (based on 12-month rolling average of the daily high watermark).
• Only 96GB per VM vRAM counts against entitlement. VMs configured with a max of 1TB vRAM, for example, would only reduce pool by 96GB.
• vCenter5 contains license monitoring/ alerting tools and will warn when pool is approaching or exceeding limits.
• List $5600/ 2 x CPU host
                

vSphere Desktop Edition

• New edition for VDI exclusive use.
• Unlimited vRAM entitlements.
• Enterprise Plus feature set.
• Licensed based on total number of powered on VMs which can be purchased with View bundle or in packs of 100.
• Current vSphere 4 licenses with SnS can upgrade to VS5 DE and get unlimited vRAM but VDI hosts cannot be managed by same vCenter hosting non-VDI related VMs.
• VDI management and monitoring tools are allowed in this license model (VCS, PVS, SQL, etc).
• Separate vCenter license still required.
• List $65/VM
  

References:

vSphere 5 licensing

vSphere 5 Upgrade Center

One of my favorite and most versatile tools in the arsenal is Microsoft Forefront Threat Management Gateway (TMG). Although “ISA” still slips out occasionally, TMG is as ISA was, a firewall, a proxy, a router, and on my short list of solutions to use if traditional methods of routing between networks is not possible, for whatever reason.

Here is a scenario: I have a private L2 network, not reachable from or connected to the corporate network. The private network, unfortunately, uses an IP scheme also in use somewhere on the corporate network. So I cannot simply attach this network to the corporate LAN directly and changing the private network architecture is just not an option right now. Enter the ultimate software network bridge: TMG. But the plot thickens… I have resources on the private side that I want to make available to the corporate network, namely a VDI pool and a Kace web server.

Planning and Design

First and foremost, I need to protect the corporate network. Nothing that goes on in the private network should be able to negatively impact the corporate LAN. This is just a common-sense precaution. With that in mind, the private network will be considered “outside” and firewalled to protect the “inside” LAN. I only have 2 networks in this scenario so a simple perimeter network configuration with 2 interfaces will suffice. My TMG server will be virtual, of course, hosted on an ESXi server with physical connections to both networks. The guest OS will be Server 2008 R2 running TMG 2010, SP1. Because the private network will be considered “the internet”, for all intensive purposes, I will have to reverse publish/ proxy those resources I wish to make available to the internal network. Here is the topology I will be implementing:

This design is typically opposite of what you would normally do with TMG, where you might publish OWA or some other internal resource to the internet. I’ve also used TMG to route specific protocols between otherwise disconnected networks. The end result of this architecture is that users on the LAN side will be able to access the published resources on the “outside”. For this exercise I will be reusing the TMG server’s inside IP address to publish my web server. So users inside will be able to browse to http://10.1.1.50 and be able to view the website hosted on 192.168.1.10.

Setup

All the basic ISA/ TMG setup best practices still apply. Define the networks your internal and external NICs connect to, use a gateway and DNS on only one (the other will be static routed), disable all protocol stack services on the outside interface (NetBIOS, etc), set the NIC binding order properly, etc. These practices are all very well documented so I won’t cover them here. There is also nothing special to configure in the TMG network rules. You don’t need to create a External to Internal route or NAT rule. The magic is all in the publishing rule.

First, create a new Web Site Publishing Rule from within the Firewall Policy tab. Give it a name and set the rule action to Allow. Publish a single web site and decide if you want SSL to protect the server connection between TMG and the web server. For this exercise I will not be using SSL.

Because DNS on the LAN side does not resolve anything in the private network, we need to specify an IP address for the internal web site. Enter the site name, check the box to use an IP address and enter it. We can’t use this site name because it isn’t resolvable but the wizard requires it, we will change it once the setup is complete.

We don’t need to enter a specific path for this website and accept requests for any domain name. Next we need to create a web listener, click New and enter a name.  Choose do not require SSL and select the Internal network to listen for incoming web requests.

Select No Authentication and finish to complete the listener setup. Once complete the listener should look like this:

TMG has the ability to pass authentication requests made by published web servers to clients. In this case we don’t need this so ensure that delegation and direct client authentication are disabled. This rule will apply to all users. Once the base rule is created there are still a few tweaks to be made before it will work as intended.

Open the new rule you just created. On the “To” tab, change the published site entry to the IP address and delete the IP in the second field. Ensure that requests are set to appear to come from TMG.

On the “Public Name” tab, change the rule to apply to “requests for the following sites” and enter TMG’s inside IP address.

Now the secret sauce: Link Translation. Without this, the home page may load but every link a user would click on the website would be directed back to the source web server’s IP address. These requests will fail because there is no routing from the corporate LAN to the private network. Link translation will replace the true source IP address mapping with the TMG server’s IP address. On the Link translation tab, click apply link translation to this rule, then click configure.

The mappings button will show you all translations applied to that rule in a web browser report. At this point, after clicking apply, you should be able to test the rule by clicking the Test Rule button. This will initiate a path ping to ensure the destination is reachable as configured. Before it will take effect, you will need to apply the rule in TMG. Now you can test by accessing the website on the corporate LAN side.

Publishing the VDI host will be similar using standard http/https to access the resources. Link translation will again be the key there to ensure that everything that is published through TMG will appear to be hosted by TMG to the end user.