i didn’t really have sufficient reason for rooting the mytouch 4g when it was my main phone. since i’ve moved on to another phone i figured why not root it now.

the process wasn’t that difficult, but it felt more involved than the process for the tmobile g1. also i made a couple of mistakes that made the process take way longer than it should have.

the ADB (android debug bridge) is required; it’s a component of the android SDK. i have the android SDK installed via the eclipse IDE. something i found odd is that the SDK isn’t located in the eclipse directory. the path is ~/android-sdks/platform-tools, from this directory ADB can be ran like so: ./adb

./adb devices will list android devices currently connected via usb.

one thing i missed here was that USB debugging must first be enabled on the phone by going to Settings->Applications->Development->USB debugging. also you’ll want the phone to connect in a “charge only” state to avoid permission errors when copying to the phone’s sdcard.

when i was messing around troubleshooting i gathered the following info:

root@emobile:/etc/udev/rules.d# lsusb
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 05ca:1814 Ricoh Co., Ltd HD Webcam
Bus 002 Device 008: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse
Bus 002 Device 016: ID 0bb4:0ff9 HTC (High Tech Computer Corp.) Desire / Desire HD / Hero (Charge Mode)

root@emobile:/etc/udev/rules.d# udevadm info -q all -n /dev/bus/usb/002/016
P: /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4
N: bus/usb/002/016
E: BUSNUM=002
E: DEVNAME=/dev/bus/usb/002/016
E: DEVNUM=016
E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4
E: DEVTYPE=usb_device
E: DRIVER=usb
E: ID_BUS=usb
E: ID_MEDIA_PLAYER=htc_desire_hero_evo-4g_legend
E: ID_MODEL=myTouch_4G
E: ID_MODEL_ENC=myTouch\x204G
E: ID_MODEL_ID=0ff9
E: ID_REVISION=0226
E: ID_SERIAL=T-Mobile_myTouch_4G_SH16VRM02504
E: ID_SERIAL_SHORT=SH16VRM02504
E: ID_USB_INTERFACES=:080650:
E: ID_VENDOR=T-Mobile
E: ID_VENDOR_ENC=T-Mobile
E: ID_VENDOR_ID=0bb4
E: MAJOR=189
E: MINOR=143
E: PRODUCT=bb4/ff9/226
E: SUBSYSTEM=usb
E: TAGS=:udev-acl:
E: TYPE=0/0/0
E: UDEV_LOG=3
E: USEC_INITIALIZED=5833363341

and here’s absolutely everything you need to know for installing cyanogenmod on the htc glacier:
http://wiki.cyanogenmod.org/w/Install_CM_for_glacier

some ADB info:
http://developer.android.com/tools/device.html

this is the first time i’ve had to struggle with setting up google voice as my primary voicemail provider (that i can recall). it’s not a difficult process on the galaxy s3, but it’s rather confusing if you don’t know what the process is.

first thing you need to do is contact tmobile and have them turn off your tmobile provided voicemail. this can be done over a support chat. then access your google voice account on the web and deactivate and reactivate your phone. google voice should now be your primary voicemail provider.

i didn’t find the uninstall/change option in Programs and Features to be very useful for determining which SQL server components are actually installed. this method also requires access to the original installation media.

a quicker method is to go to:
…Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log
and finding the Summary.txt file(s).

here’s an example of the file contents:

Product features discovered:
Product Instance Instance ID Feature Language Edition Version Clustered
Sql Server 2008 R2 MSSQLSERVER MSSQL10_50.MSSQLSERVER Database Engine Services 1033 Standard Edition 10.50.1600.1 No
Sql Server 2008 R2 MSSQLSERVER MSRS10_50.MSSQLSERVER Reporting Services 1033 Standard Edition 10.50.1600.1 No
Sql Server 2008 R2 Management Tools – Basic 1033 Standard Edition 10.50.1600.1 No
Sql Server 2008 R2 Management Tools – Complete 1033 Standard Edition 10.50.1600.1 No
Sql Server 2008 R2 Integration Services 1033 Standard Edition 10.50.1600.1 No

Package properties:
Description: SQL Server Database Services 2008 R2
ProductName: SQL Server 2008 R2
Type: RTM
Version: 10
SPLevel: 0
Installation location: D:\x64\setup\
Installation edition: STANDARD

source:
http://www.sqlservercentral.com/Forums/Topic871318-391-1.aspx

both of these components can be installed on a windows vcenter server from the vcenter install media. they come natively on the VCSA (vcenter server appliance).

of course, it’s necessary to point the ESXi hosts to these new collector locations.

details below:
http://blogs.vmware.com/vsphere/2011/07/setting-up-the-esxi-syslog-collector.html
http://blogs.vmware.com/vsphere/2011/07/setting-up-the-esxi-50-dump-collector.html

update 9/27/2013:
quick commands to set the syslog collector…
esxcli system syslog config set –loghost=<ip address>
esxcli system syslog reload

FLEXlm licensing managers have been a pain for me for years and it seems that every network-licensed application uses it now. usually it’s no problem if you just install FLEXlm for one product, but as you co-locate various products that use FLEXlm it can lead to issues.

overall, it’s not that difficult to fix if you stop to take a look at what’s going on.
start by running lmtools.exe and going to Config Services then using the View Log option for the various services. you’ll be able to see if the licensing service/daemon was able to successfully start and what port it’s running on..for instance “lmgrd tcp-port 27002”. the problem i seem to always is experience are services that try to run on the same port. TCP port 27000 seems to be a somewhat default choice.

luckily, the port can be changed by opening the related .lic file in a text editor and locating the SERVER section of the document. there should be an entry similar to “SERVER hostname 27000”, the last part being the port number. just change that value to an unused TCP port.

example server running FLEXlm services on multiple ports:
ML 27000
RS 27001
MPL 27002
AG 27003
QTS 27004
SW 25734

some related info here:
http://www.mathworks.com/support/solutions/en/data/1-16RGP/?1-16RGP

update 2/19/2015:
the license manager for AG also wanted to default to port 27000, changed it to 27003 by editing its service.txt file.

you need to install a new vMA virtual appliance for 5.1 (a 4.x appliance can not be upgraded to 5.1).

vMA 5.1 is backwards compatible with 4.1 hosts. on initial power-on of the new appliance i received an error similar to “…network has no associated network protocol profile”. evidently, the new appliance is configured as a vApp by default. i had no interest in vMA being a vApp and so on the VM itself, i went to Edit Settings->Options->vApp Options and chose disable.

final note, the password requirements for the vi-admin account seem to be stricter than before.

update 12/6/2013:
vma upgrades are no longer done through the command line. instead you will need to browse to https://vma:5480 and go through the update process there after mounting an iso to the appliance.

update 1/21/2014:
there’s the upgrade feature i mentioned in a previous update, but oddly enough it’s not used in the transition to vma 5.1 to 5.5. the vma 5.5 appliance has to deployed from scratch. source: https://www.vmware.com/support/developer/vima/vma55/vma_55_relnotes.html#priorreleases

i’m not sure if this has always been the behavior, but this is how things currently function in our environment.

user’s AD account disabled:
can still use OWA
can not login to endpoints/access AD resources

user’s AD account expired:
can still use OWA
can not login to endpoints/access AD resources

exchange mailbox disabled:
cannot access OWA
mailbox disconnected and marked for deletion

i upgraded vcenter 4.1 to 5.1 a few nights ago. the whole process took about 3.5 hours for me because of a couple of hiccups during the install and an unexpected surprise after the install finished.

i did all of the SSO database prep work previously so i didn’t have to deal with that at install time. the SSO component is installed first. it installed fine with no complaints besides saying it couldn’t detect the AD domain settings (even though i specifically logged in as a domain user for this). i saw online that other people have experienced this and noted in the vmware docs that i could just add the domain settings later. so, the SSO part was not a concern to me so far. i should note that the SSO admin account/password (admin@System-Domain) is very important in this release so be sure to commit it to memory or notate it somewhere.

next you install the inventory service. i didn’t experience any problems here.

and lastly, the vcenter component is installed. here’s where i experienced a couple of problems. the vcenter 5.1 installer seems much pickier than previous vcenter installers…

problem #1
in the midst of the vcenter install, a dialog window popped up saying that SSL certificate verification for hosts was disabled and the installer could not proceed further without this feature being enabled. unfortunately, the only way you can enable this setting is to cancel the install, restart the vcenter service, and then login with a vsphere client and enable the setting. i manually verified each host in hopes of avoiding further issues.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2035594

problem #2
another SSL certificate issue. this time the installer pointed out that the vcenter’s own SSL certificate was expired. something like this had never ever even crossed my mind before. it had probably been expired for years and never caused an issue. so i’m thinking at this point, okay installer, generate a new cert then… after all it’s just a self-signed cert, so what’s the big deal? well it’s not quite that convenient of a process. and during moments like this it’s a godsend to have a linux machine within reach. so i used openssl on linux to generate a new cert. i suppose you could install openssl on windows, but i have no idea if that’s a hassle or not. in linux, openssl is pretty much just always there. the good news is that this new cert should last for 10 years.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009092

after fixing the above 2 problems the upgrade eventually finished. during the install process i was warned that certain pre-existing administrators would be losing access. the installer indicated that the accounts affected would be notated in 2 text files. i could not locate these text files with a file search for some reason. i recalled vaguely reading about something like this in the docs, but had thought that accounts that had local administrator access would be either unaffected or auto-readded. well…i definitely thought wrong, but i’ll get to that later…

immediately after the upgrade finished i launched the vsphere client on my workstation and proceeded to upgrade the client. i could not login with my AD credentials with the new 5.1 client. i did a quick google for something like “can’t login after vcenter 5.1 upgrade” and saw a page or two of related blog posts. so i immediately thought oh great it’s going to be one of those type of things…

common sense told me that it had to be related to the new SSO stuff. and i knew from earlier that SSO was unaware of my AD domain. so after some quick research i found out that SSO settings can only be configured from the vsphere web client. i logged in with the admin@System-Domain account. then i went to Administration->Sign-On and Discovery-Configuration->Identity Sources.

the first thing you’re going to want to do is configure your AD domain as a identity source. here’s an example:
Type: Active Directory
Name: (something meaningful to you that describes your domain)
Primary server URL: ldaps://dc.mydomain.com:636 (LDAPS isn’t mandatory)
Base DN for users/groups: (if you leave this blank it will auto-populate with the root of your domain)
Domain name: mydomain.com
Domain alias: MYDOMAIN (i originally left this blank because it’s listed as optional in the docs. you won’t want to leave this blank…i’ll go into this later)
Authentication type: Password (i created an AD user with read-only access to the domain to be used for this)

then i tested the connection and added this identity source to the list of default domains. also i moved it to the top of the list. i took a minute to go to “SSO Users and Groups” and added the Domain Admins group to the SSO Administrators group (named __Administrators__) as well. a final note, if you mess up anything when setting up the identity source, you can’t easily edit it and fix your mistake. a lot of times you’ll need to delete it and recreate it from scratch.
http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.security.doc%2FGUID-B23B1360-8838-4FF2-B074-71643C4CB040.html
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2035758

i was ready to test my AD login again with the vsphere client at this point. in the mean time, i also had the vsphere client upgrading on the vcenter server. this time around i determined the “mydomain\username” format was no longer being accepted, but “username@mydomain.com” was. “mydomain\username” and the Use Windows session credentials options would both return incorrect username or password. when using “username@mydomain.com” i would get a different error. something along the lines of “user does not have permissions to vcenter server”. so i was getting closer…

however, at this point it was getting to be late at night and i was running out of ideas. i think i’ve gotten to a point in my life where staying really late at work is no longer cute. i prefer to be at home and comfortable now and try to avoid excessive late work hours if i can. so i dialed up vmware support to expedite the situation. support quickly determined what was going on. this was the surprise i didn’t count on… either it was it unclear in the vmware docs or i somehow missed it entirely. so what happens after a vcenter 5.1 upgrade is that all vcenter user permissions are completely wiped out except for the lone vcenter administrator account (local administrator on the vcenter server). you have to login to the vsphere client on the vcenter server with this account and then reset all the user permissions to vcenter from the vsphere client. i’m fairly certain i had to specify the Adminstrator login in this format “<your vcenter server name>\Administrator”. so the immediate problem was quickly solved. and i was really glad i cleaned up the vcenter access groups in AD a few months prior. if someone potentially had a ton of VMs with individual user access set on them…then they’d have a really long night ahead of them.

i wasn’t quite ready to end the support call though. as i mentioned above the Use Windows session credentials option was still not functioning with the vsphere client. support eventually determined it was because i did not specify the domain alias in the SSO identity source for the AD domain. the reason i did not do this was because it was listed as optional in the vmware documentation.

some useful install visuals here:
http://www.virtuallyimpossible.co.uk/updating-vmware-vcenter-from-5-0-to-5-1/

update 4/9/2013:
forgot to notate that the port for the vsphere web client is 9443…therefore https://vcenter.mydomain.com:9443.

i’ve been reading over the docs for upgrading to vcenter 5.1 the only gotcha i’ve come across is the manual setting up of the SSO (single sign-on) database and users. you would only do this if you were using a database other than sql express (which i imagine everyone does, at least in production). anyways, the steps necessary to set up the DB are very well documented.

the scripts are on the vcenter install media:
d:\single sign on\dbscripts\ssoserver\schema\mssql

edit the “CHANGE ME” portions of the rsaIMSLiteMSSQLSetupTablespaces.sql script to the location of where the SSO databases should reside.
a typical location might be: c:\program files\microsoft sql server\mssql10.mssqlserver\mssql\data

run the script and RSA_DATA.mdf, RSA_INDEX.ndf, and translog.ldf will be created.

next edit the password portions of rsaIMSLiteMSSQLSetupUsers.sql and then run it.

SSO database work should be complete at this point.

i almost missed this fact because it’s not very clear in the docs, but is stated in many blogs. sql server authentication needs to be changed to mixed mode as RSA_DBA and RSA_USER are SQL users.

sources:
http://vmwaremine.com/2012/11/12/prepare-dbs-for-vsphere-5-1-installation-or-upgrade-part-1/
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2034918#db
http://thephuck.com/virtualization/how-to-create-a-database-for-vcentersinglesignon-using-sql-express-2008-r2-vmware-vcenter-sso-vsphere51/
http://virtualpotholes.wordpress.com/2012/10/26/installing-vcenter-single-sign-on-with-sql-server/

here’s another procedure that doesn’t come up too often…raising the AD functional levels.

to check the current forest and domain functional levels go to AD Domains and Trusts and then right-click on the domain name and choose properties. both functional levels should be listed.

raise domain functional level: right-click the domain name and choose “Raise Domain Functional Level”

raise forest functional level: right-click the root (top entry) of AD Domains and Trusts and choose “Raise Forest Functional Level”

the domain functional level should be raised prior to raising the forest functional level.