Wednesday, June 09, 2010

Ubuntu AMR Codec

What a PITA. I have a cool smart phone that takes video, and can't get audio to work in Ubuntu, since Intrepid and Jaunty don't appear to come with AMR codecs compiled in ffmpeg, or gstreamer.

Now, you can try to compile your codecs from source, and I've certainly done this sort of thing before; I can build my own kernel (In the days BEFORE xconfig), run Slackware/Gentoo, etc. This just didn't work for me.

BUT, there is an easy solution.

YOUTUBE.COM

Image representing YouTube as depicted in Crun...Image via CrunchBase

That's right. Upload your video to YouTube, wait for it to process, and download the resulting MP4 from the My Videos area of the control panel. Presto, you've got your audio converted to something usable in short order.

Enhanced by Zemanta

Windows 2003 Migration

I haven't had to do a migration for some time, since the days of consulting have been over for 3 years now.

IMG_2459Image by mooing brontosaurus via Flickr

Even then, I'd only done a couple of 2000 to 2003, and one SBS 2000 to SBS 2003 migrations.

This project involved moving from SBS 2003 to a Standard 2003 environment. I was a bit intimidated, and purchased the excellent Swing It! SBS Migration kit from Jeff Middleton. One good thing about it was that Exchange had been moved to a hosted solution last year, and they didn't use Sharepoint.

Turns out this was a good purchase for a guy doing a solo project with few peers to bounce questions or ideas off of. Jeff freely provides answers and guidance in his forums, and his expert help is just a phone call away if you are current with your subscription. Pre-pay, and your support requests are responded in an even quicker manner.

Fortunately, I didn't need to ask but a few questions, and I was on my way with the docs, and tool-sets provided by the kit.

I started the process by setting up a temporary DC in a virtual environment, then basically took the following steps to gradually move away from the old SBS box:

  1. Migrate all file, print, dhcp, http, etc off of SBS to the temp DC or a member server.
  2. Promote temp DC, and give it a copy of the GC.
  3. Check Application log for successful AD transfer, DNS.
  4. Install WINS if necessary on temp DC and create replication partner to SBS for transfer of info.
  5. Take temp DC off-line, unplugging works better since some services like DNS and WINS don't like the NIC disabled.
  6. Seize all FSMO roles from SBS machine. It will complain and appear to error, but this is normal.
  7. Use ntdsutil to remove all SBS references in metadata.
  8. Remove all SBS references in DNS, and WINS. This is where Jeff's tools shined, and saved me lots of time.
  9. Unplug NIC on SBS box, and bring temp DC online.
  10. Enjoy an SBS-Free zone.

In this scenario, the temp DC can be a temporary, or permanent location for AD to reside. It's really up to you. Just keep in mind that if you have your only AD DC virtualized, and it's your ONLY DNS server, that you realise you may have issues with users logging in, or other DNS related problems until your virtualized DC comes up.

For this project, we opted to install a small 1U 2008 AD server, that holds all FSMO roles.

A couple of things to note for me was:

  • If you have other AD DNS servers in the environment, remove DNS from them, otherwise you'll be cleaning references to the old SBS off them, and causing bigger issues for yourself when you bring your temp DC back online.
  • Double-check your login scripts for references to your old SBS box.
  • Check printers and other devices that have static IP addresses to ensure those settings reflect your environment changes.
Reblog this post [with Zemanta]