Monday, January 31, 2011

Exchange 2010 - Can't Download OAB

During a migration from Exchange 2007->Exchange 2010, I could not figure out why my OAB would not download after deleting & re-creating it.

Originally, we were having an issue where Outlook 2003 clients would throw "Task 'Microsoft Exchange Server' reported error (0x8004010F): "The operation failed.  An object could not be found." when attempting to send/receive.  I tracked the issue down to the OAB after a short Google search. 

Our OAB virtual directory was actually empty, and there was no GUID folder before I found the solution below.

When attempting to download the OAB directly from Exchange 2010, one would receive the message: "An error occurred while opening the Microsoft Exchange Offline Address Book files," and event ID 27 (source: Outlook), "The operation failed," would be recorded in the application event log.

This post provided the solution.  After running the command in Exchange Management Console on the 2010 server:

update-FileDistributionService

I was able to download the OAB successfully from Outlook 2010.

Saturday, December 25, 2010

Disable OTA Updates Android

Ok Verizon was just pissing me off by pushing the OTA updates to my phone.  After dealing with "Install later" for 3 weeks, I finally managed to disable OTA updates using a trick I found on a forum.

First, make sure you have adb installed & that it can pick up your device.  Next, adb shell into your device & type the following commands:

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
cd /system/etc/security
mv otacerts.zip otacerts.zip.bak
mount -o ro,remount -t yaffs2 /dev/block/mtdblock3 /system
sync
reboot

Wednesday, November 3, 2010

Building MochaUI.js From Git

This one really drove me insane.  I recently discovered JavaScript MooTools library & it's UI component, MochaUI.  MochaUI provides a powerful & easy-to-use library for developing rich internet applications (RIAs).

My issue began after finding that the version on the website was highly out of date.  I was looking to use OmniGrid alongside MochaUI, but the latest released version is mochaui-0.9.7.

After cloning the Git, I discovered that the new Demo contained far more features, and was much better laid out than the 0.9.7 release.  I also found that the JavaScript files were provided as "source" to MochaUI.  This confused the hell out of me, as how would I "build" JS files?!  Three hours later after scouring Google & the terrible documentation on github, I managed to find this blog post which pointed me in the right direction.

It turns out each MooTools component contains a "package.yml" YAML file which is fed to a PHP script called "Packager."  Package simply concatenates the source files listed in the manifest (package.yml) together.  So much for "building" the JS :/.

Here's the complete steps to produce a "mochaui.js" file from github.

First, clone the MochaUI codebase & cd to the new directory:

[user@box:~/Desktop/test]$ git clone git://github.com/mui/mochaui
Cloning into mochaui...
remote: Counting objects: 11437, done.
remote: Compressing objects: 100% (4806/4806), done.
remote: Total 11437 (delta 6610), reused 10172 (delta 5745)
Receiving objects: 100% (11437/11437), 3.29 MiB | 2.85 MiB/s, done.
Resolving deltas: 100% (6610/6610), done.

[user@box:~/Desktop/test]$ cd mochaui/
Next, I had to modify the "package.yml" file to point to the correct sources directory.  The original was incorrect, containing the wrong path & core files.  Note: You must have the source files listed in this exact order, lest nothing will work properly.

My new "package.yml" file looked like so:

name: "MochaUI"

version: "0.9.8-dev"

exports: "mochaui.js"

web: "[mochaui.com](http://mochaui.com/)"

description: "MochaUI, A web applications user interface library"

license: "[MIT License](http://mochaui.com/demo/license.txt)"

copyright: "© [AUTHORS.txt]"

authors:
  - "[Chris Doty](http://polaropposite.com/)"
  - "[Greg Houston](http://greghoustondesign.com/)"
  - "Scott F. Frederick"
  - "Joel Lindau"
  - "Harry Roberts"

sources:

   - "Source/Core/Core.js"
  - "Source/Core/Canvas.js"
  - "Source/Core/Content.js"
  - "Source/Core/Desktop.js"
  - "Source/Core/Column.js"
  - "Source/Core/Panel.js"
  - "Source/Core/Dock.js"
  - "Source/Core/Window.js"
  - "Source/Core/Modal.js"
  - "Source/Core/Themes.js"

Next, I proceded the use the same steps above to clone Packager from: git://github.com/kamicane/packager.

Once cd'ed into my packager directory, I ensured that I had PHP installed.  That's an entirely different subject, but if you have access to the "php" command, enter the PHP interactive shell with the command "php -a"

[user@box:~/Desktop/test/mochaui/packager]$ php -a
Interactive shell

php > require_once('packager.php');
php > $pkg = new Packager('replace_with_path_to_package.yml');
php > $pkg->write_from_files('mochaui.js', $pkg->get_all_files());
php > exit

Once in the interactive shell, we need to include the "packager.php" file with the require_once() method.  Once PHP knows about the Packager class, we can create a new instance.

As per the git's documentation (https://github.com/kamicane/packager), we can see that the constructor to the Packager instance is simply the path to the "package.yml" manifest file.  In my case, this is simply the parent directory.  Next, the write_from_files() method takes two parameters, but we really only need to know about the first.  This is the output file name.  Considering we are building the "mochaui.js" file, that's what the parameter will be.

After exiting the PHP shell, your Packager should now contain the fully "built" mochaui.js file.

Hopefully that'll save you some time & research :).

Monday, November 1, 2010

Windows XP Left Pane Missing

A client recently struggled when his XP workstation's left pane disappeared.  This pane contains commons tasks such as emailing files.

A simple registry modficiaton was needed to remediate the issue:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]
"WebView"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"ClassicShell"=dword:00000000
 
After applying the fix, I killed the "explorer.exe" process, then re-opened it.  The pane was now visible.

Wednesday, October 6, 2010

Gnome Decent Dual Monitor Wallpaper Span

Tired of trying to use compiz to have wallpaper span both screens, only to find your desktop icons disappear?

A few months ago I embarked on a relentless search through mountains of RGBA patches, custom versions of nautilus, and failed attempts at allowing desktop icons to pierce through compiz's iron curtain.

Finally created a decent method of having wallpaper span dual monitors in Gnome by overriding Gnome's "Spanned" desktop setting (I don't think it works right anyway) with a "Zoomed" dual monitor setting.  I first tried this by scaling the image directly, but it looked like crap so I figure Zoom would be better to use.  The result is not perfect, but definitely better than waiting 15 years for the Gnome team to come up with a plausible solution.

The steps I took were for Arch Linux, but you can apply them equally well to any distribution, as long as you know how to make packages from source.

After reading through this bug, I realized I should be modifying the desktop settings directly.

I checked my Gnome version through pacman, and proceeded to download the PKGBUILD straight from the Arch SVN.  After receiving the source code, I ran "makepkg" once to ensure the source would compile properly, then proceeded to comment out the following lines in the PKGBUILD file:

#source=(http://ftp.gnome.org/pub/gnome/sources/${pkgname}/2.32/${pkgname}-${pkgver}.tar.bz2)
#sha256sums=('blahblah')

To ensure that the source code would not be downloaded again & overwrite my modifications.

Next, I proceeded to open the "src/gnome-desktop-2.32.0/libgnome-desktop/gnome-bg.c" file, and commented out the following line, simply copying the Gnome "Zoom" option's code to the "Span" section of the case statement:

#if 0
    g_print ("original_width: %d %d\n",
         gdk_pixbuf_get_width (pixbuf),
         gdk_pixbuf_get_height (pixbuf));
#endif
   
    switch (placement) {
    case GNOME_BG_PLACEMENT_SPANNED:
                // new = pixbuf_scale_to_fit (pixbuf, width, height);
        new = pixbuf_scale_to_min (pixbuf, width, height);
        break;
    case GNOME_BG_PLACEMENT_ZOOMED:
        new = pixbuf_scale_to_min (pixbuf, width, height);
        break;
       
    case GNOME_BG_PLACEMENT_FILL_SCREEN:
        new = gdk_pixbuf_scale_simple (pixbuf, width, height,
                           GDK_INTERP_BILINEAR);
        break;
       
    case GNOME_BG_PLACEMENT_SCALED:
        new = pixbuf_scale_to_fit (pixbuf, width, height);
        break;
       
    case GNOME_BG_PLACEMENT_CENTERED:
    case GNOME_BG_PLACEMENT_TILED:
    default:
        new = pixbuf_clip_to_fit (pixbuf, width, height);
        break;
    } 
Finally, in the next section continaing the "GNOME_BG_PLACEMENT_SPANNED" (around 20 lines down from the previous section), I made the following modification to the code--commenting out what is commented in blue, and replaced with the code in red:

    scaled = get_scaled_pixbuf (placement, pixbuf, dest_width, dest_height, &x, &y, &w, &h);

    switch (placement) {
    case GNOME_BG_PLACEMENT_TILED:
        pixbuf_tile (scaled, dest);
        break;
    case GNOME_BG_PLACEMENT_ZOOMED:
    case GNOME_BG_PLACEMENT_CENTERED:
    case GNOME_BG_PLACEMENT_FILL_SCREEN:
    case GNOME_BG_PLACEMENT_SCALED:
        pixbuf_blend (scaled, dest, 0, 0, w, h, x + area->x, y + area->y, 1.0);
        break;
    case GNOME_BG_PLACEMENT_SPANNED:
        // pixbuf_blend (scaled, dest, 0, 0, w, h, x, y, 1.0);
        pixbuf_blend (scaled, dest, 0, 0, w, h, x + area->x, y + area->y, 1.0);
        break;
    default:
        g_assert_not_reached ();
        break;
    }
   
    g_object_unref (scaled);

From here, I saved the source,  ran "makepkg -f" again, installed the package, and restarted Gnome.  Not perfect, but they are nice ;)

Monday, October 4, 2010

C++ -- Why do we not dereference when passing by reference?

I recently got back into trying to teach myself C++, mostly through YouTube tutorials (this guy's are pretty good).  I only went to IRC for an answer at one point, but would like to share something I found & wasn't able to Google on.

Everyone should know how to use pointers when working with C++.. say we had:

#include
using namespace std;

int main()
{
    int num = 5;
    int *pnum = #
    cout<<"integer num (@"<<<") = "<<*pnum;
    return 0;
}

Then we can see that integer num is set equal to five, and integer pointer pnum is set to the address of num.  Normally, in C++, the "&" operator refers to the address of the object the operator is being applied to.

In the case of passing values to function by reference, I was quite confused when I found that we do not in fact need to dereference the reference passed as an argument.  For example:

#include
using namespace std;

void increment_variable(int & x)
{
        x++;
        return;
}

int main()
{
        int num = 5;

        increment_variable(num);

        cout<<"integer num (@"<<&num<<") = "<<
        return 0;
}

In the increment_variable(int & x) function, we would think that to increment the value of the x variable, we would need to dereference the address of the x variable, which has been passed as a parameter.  As shown by the code, this is not in fact the case! 

 In reality, the "&" operator when used with pointers is a completely different operator than the "&" used when passing values to functions by reference.

Do not get the two confused!

Saturday, September 25, 2010

VirtualBox Adventures & Recovering plaintext data from damaged drive

As a network tech, I should always follow the golden rule of backup up data.  I recently attempted resizing a partition (after neglecting this pinnacle of IT) & completed destroyed a PHP web application I had been working on.

The PHP web application was stored in a VM on the host's ext4 partition, and I had managed to destroy both the superblock & journal of the host's filesystem.  After an unsuccessful attempt to restore the superblock from a backup on the drive, I figured the FS to be toast, but couldn't accept that the data had been completely lost.

What I really should've done was taken a DD image from the get-go with the following command:

# dd if=/dev/sda4 of=/media/Storage/Drive_Backup.img

After a bit of research and IRC chat, I was directed toward the following page: http://wiki.yak.net/592.  The script seemed perfect for what I had needed to do.  I knew the destroyed partition had only been 0.1% non-contiguous, so my hope was to completely recover the virtual hard disk image, or at least a repairable copy.
 
To begin, I created a test, dynamically expanding VDI file & opened it within a hex editor:


I could now see that each VDI file began with the string "<<< Sun Virtualbox Disk Image >>>"--the idea was to copy a large amount of data past where the script managed to locate things string, and to chop off the residual data with a hex editor.

I proceeded to test the procedure by placing the small test VDI file on an ext4 drive, searching for the data by reading the drive byte by byte, and copying only a small amount of data (~1mb) past the point where the magic string was found.  The test was successful, though I still doubted I'd be able to recover a usable VDI file.

After a bit of modification to the script posted above (http://wiki.yak.net/592), I was able to successfully pick up around 10 VDI files off my dead drive (arbitrarily sized to 4GB past the magic string).  After a bit of searching through these recovered VDI files, I found the exact file I was looking for.  Unfortunately, my suspicions were confirmed when GRUB was found, but damaged beyond repair.

At this point, after a bit more research (http://www.linux.com/community/blogs/howto-read-a-virtualbox-vm-disk-wout-starting-the-vm.html), I began to realize that all a VDI file did was encapsulate the virtualized file system within VirtualBox metadata.

From here, I scrapped the whole idea of recovering the VDI and went directly for the plain text data off the drive itself.

To search through the drive, I ran the command:

$ grep -ab "php" /dev/sda4 > grepped

 As I knew I was searching for plain text files that began with "php"--the search worked flawlessly.  The "-b" option on grep, also records the decimal memory address where each instance of the string was found.

When the search completed, I had a list of the location of every instance of the "php" tag on the drive.  This was a massive amount of data to sift through, but I managed to find the location (or at least get close to the location) of the important data I needed, by refining the search with the code's filename; for example:


Basically, we can see that a reference to the filename "MY_Controller.php" & a memory address of 391021232450 (decimal).  After heading over to the offset through wxHexEditor, I can see quite clearly that my PHP code is in fact intact:



And it's complete with formatting & indentation :).  From here, I've simply copied & pasted out each file as I found them, though some were not quite as straightforward.

It'll take a lot of hard work & determination to get your files back, so you need to decide whether it's worth it.

Also try out PhotoRec & foremost if you need to recover stuff that isn't plain text.

(I may post a condensed version of this document with only a short summarization of plain text data recovery techniques if anyone actually reads this)

-CJ

Friday, September 24, 2010

Linux Enable Write-Caching On Disk

When booting a VM recently, I received the error message below regarding I/O writecaching & virtual hard disk corruption:


After Googling for a bit, I found that the first thing to check with this error is whether I/O write caching is enabled on the VM.  In my case, it was.

Next, a lot of the posts I was reading were stating the corruption was occuring on "ext4" partitions.  I assumed that the write caching was a filesystem option.  I had heard of the disk write cache when working on Windows servers, but never really knew the specifics. 

After a bit more research, I found disk write-caching was actually a drive option that could be set with the hdparm command.  It will improve performance by 10-20%, but can also cause system instability. 

To enable write-caching on the drive, I ran command:

[user@box ~]$ sudo hdparm -W1 /dev/sda
Password:

/dev/sda:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)


And rebooted the machine, effectively taking care of the error.

Tuesday, August 10, 2010

Exchange 2007 Offline Address Book 0x80070422

If you're getting frustrated by Outlook 2007 clients receiving error 0x80070422 when trying to Send/Receive the Offline Address Book, the first thing to check is your Exchange 2007 service URL's.

The quickest way to test this from the client end would be to hold CTRL & right click your Outlook 2007 Icon.  Choose the option "Test E-mail Autoconfiguration..."


This will open up a new window (see below).  In this window, uncheck the options "Use Guessmart" & "Secure Guessmart Authentication."  Enter your password & hit "Test."

If your AutoConfiguration test completes successfully, then you're probably wondering why you're still receiving error 0x80070422.  If your email AutoConfiguration test does not complete successfully, please verify your Exchange 2007 Web Service URL's as per this article.

Once you resolve any issues with email AutoConfiguration, many Outlook 2007 issues will also follow!  A good example would be when you know that your server certificate is valid, yet you're still receiving a security warning similar to:
 Check those service URL's!

Now, the next step to remediating your 0x80070422 error (which is a CLIENT SIDE ERROR), enable the BITS service on the client PC.

Sunday, July 18, 2010

USB Drive Fstab UUID (Arch Linux)

Just had an issue where I could not mount my USB drive at boot time I was getting an error along the lines of UUID=blah not found...I previously had performed the standard "sudo blkid" and received the following output:

[corte@ashbox ~]$ sudo blkid
Password:
/dev/sda1: LABEL="Boot" UUID="3a31d197-0436-4b87-9f06-b03080a3772f" TYPE="ext2"
/dev/sda2: UUID="ea73d633-0f71-43a3-9101-6461f19b1222" TYPE="swap"
/dev/sda3: LABEL="Root" UUID="63b1459a-3ee6-4d7a-9afa-9ad40db800bd" TYPE="ext4"
/dev/sda4: LABEL="Home" UUID="00e59ee8-019b-4ad2-9171-e8501a1022c3" TYPE="ext4"
/dev/sdb1: LABEL="Elements" UUID="7da36762-56c3-471d-bfa1-5b4895bfa0d7" TYPE="xfs" 

Noting the UUID of my external USB drive (Elements), I added the following line into my fstab file:

UUID=7da36762-56c3-471d-bfa1-5b4895bfa0d7 /media/Elements auto defaults 0 0

 Everything went dandy with a "mount -a" yet at the next reboot, I received an error stating that the device with the UUID 7da..could not be found.  A bit of research lead me to the solution...
Including "usb" before "filesystems" in the hooks section of your /etc/mkinitcpio.conf file:

 HOOKS="base udev autodetect pata scsi sata usb filesystems v86d"

Regenerate your mkinitcpio file with: 


sudo mkinitcpio -g kernel26.img

Then be sure to make a backup of your old /boot/kernel26.img

sudo mv /boot/kernel26.img /boot/kernel26.img.bak

Finally, copy your new kernel26.img to /boot.

cp kernel26.img /boot/kernel26.img 

Now reboot and your external drive should be mounted automatically with no issues.