Archive for January, 2013

Android phone unable to connect to Exchange Server

After a local server maintenance, my Galaxy Nexus (Android 4.1.1) stopped connecting to the Exchange Server.
I removed the account to try re-adding the account and doing so lost all my emails, calendar and contacts.

No matter how hard I tried, I could not add my account “wind\jason.bickley”.
I always received the error “Could not connect to the server”.

However, when I tried puting in an intern’s credentials it could connect.
Our I.T. Manager then found the following solution and corrected it in Active Directory.

http://technet.microsoft.com/en-us/library/dd439375(EXCHG.80).aspx

“In Exchange Server 2010, you may also experience this issue if the Exchange Servers group does not have the appropriate permission to the mailbox object in Active Directory. The most common cause for this is broken Access Control List (ACL) inheritance in Active Directory.”

To check whether inheritance is disabled on the user:

  1. Open Active Directory Users and Computers.
  2. On the menu at the top of the console, click View > Advanced Features.
  3. Locate and right-click the mailbox account in the console, and then click Properties.
  4. Click the Security tab.
  5. Click Advanced.
  6. Make sure that the check box for “Include inheritable permissions from this object’s parent” is selected.

If the user is a member of certain protected groups such as Domain Administrators, it is normal for this box to be unchecked. If you are experiencing a problem with members of these protected groups you should check the permissions on the AdminSDHolder object.”

Google Analytics Multiple Tracking Code

Here is a cool trick I have implemented across the EWEA web platform:

<script type="text/javascript">
 var _gaq = _gaq || [];
 _gaq.push(['_setAccount', 'UA-xxxxxxxx-yy']);
	_gaq.push(["_setDomainName", "none"]);
	_gaq.push(["_setAllowLinker", true]);
	_gaq.push(["_trackPageview"]);
 _gaq.push(['_setAccount', 'UA- xxxxxxxx-zz'']);
	_gaq.push(["_setDomainName", "none"]);
	_gaq.push(["_setAllowLinker", true]);
	_gaq.push(["_trackPageview"]);
 (function() {
	var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
	ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
	var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
	})();
</script>

This goes at the bottom of the tags and what it does is this:

• The “yy” code is for the local site, i.e. our individual event site or our blog.
• The “zz” code is common on all the sites. This gives me a global view over all the sites as to the most popular content across all platforms.

Fix “PHP Fatal error: Call to undefined function get_header()” error in WordPress

Taken from http://www.ardamis.com/2011/06/02/fix-for-php-fatal-error-get_header-in-wordpress/

While making changes to my WordPress theme, I noticed that the error_log file in my theme folder contained dozens of PHP Fatal error lines:

[01-Jun-2011 14:25:15] PHP Fatal error:  Call to undefined function  get_header() in /home/accountname/public_html/ardamis.com/wp-content/themes/ars/index.php on line 7
[01-Jun-2011 20:58:23] PHP Fatal error:  Call to undefined function  get_header() in /home/accountname/public_html/ardamis.com/wp-content/themes/ars/index.php on line 7

The first seven lines of my theme’s index.php file:

<?php ini_set('display_errors', 0); ?>
<?php
	/*
	* @package WordPress
	* @subpackage Theme
	*/
	get_header();
?>

I realized that the error was being generated each time that my theme’s index.php file was called directly, and that the error was caused by the theme’s inability to locate the WordPress get_header function (which is completely normal). Thankfully, the descriptive error wasn’t being output to the browser, but was only being logged to the error_log file, due to the inclusion of the ini_set(‘display_errors’, 0); line. I had learned this the hard way a few months ago when I found that calling the theme’s index.php file directly would generate an error message, output to the browser, that would reveal my hosting account username as part of the absolute path to the file throwing the error.

I decided the best way to handle this would be to check to see if the file could find the get_header function, and if it could not, simply redirect the visitor to the site’s home page. The code I used to do this:

<?php ini_set('display_errors', 0); ?>
<?php
/**
* @package WordPress
* @subpackage Ars_Theme
*/
if (function_exists('get_header')) {
	get_header();
}else{
    /* Redirect browser */
    header("Location: http://www.ewea.org/SITENAME/");
    /* Make sure that code below does not get executed when we redirect. */
    exit;
}; ?>