Exchange Server,, Alias Addresses and the unnecessary self CC on “Reply all”

If you’re using Apple’s in conjunction with an Exchange server where you have an account that is also configured to use an alias address, you may have encountered an odd problem where anytime you hit “Reply All” to a message, your alias address is included on the CC line of the email.

This had been happening to me for quite some time.  Instead of searching for a solution and resolving the issue, I dealt with it by simply deleting the address on the CC line before sending.  This morning, though, I decided to take a few minutes to try to permanently resolve the issue.

It turns out it’s a pretty easy fix, likely caused by an odd quirk in the way that handles Exchange account information.

When you set up your Exchange account on OSX, the information about your configuration to the mail server that the application uses on each startup is stored in a .plist file called “Accounts.plist”.  This file is located in the /Users/{username}/Library/Mail/V2/MailData/ directory.  The quickest way to get to and edit this file is to use Finder’s Go>Go To Folder menu, and type in the folder name.  When you see the Accounts.plist file, open it for editing (make sure that you’ve shut down before attempting to edit).

A .plist file is a simple XML file used by OSX apps to store and read configuration data on startup.  Because these files are XML based, you should be able to read and edit them with any capable text editor.  I prefer Bare Bones Software’s BBEdit but any text editor should work.

The basic structure of this XML file is as follows:




Account Information



Search the various accounts in your DeliveryAccounts array until you find the Exchange account, listed as an “EWSAccount” in the Account Type section of the XML.  Within this block of XML code, you’ll see a key named “EmailAddresses”, followed by an array with the email addresses associated with this account listed.  If you’re experiencing the self-CC problem, it’s unlikely that the alias that you use with your Exchange account is listed here.

Just add an additional string value to the email address array, inserting your alias address between the <string>..</string> blocks.

Here is a before and after of my EWSAccount section:




Accounts_plist 2

After making this change, save the file, restart, and try reply-all.  You should no longer see the self-CC appear on the CC line of the email.



Access Data Projects and Microsoft Office 2013

When Microsoft released the 2013 version of their Office suite, the version of Microsoft Access that was included dropped support for a feature known as Access Data Projects.   Access Data Projects were a (in my opinion) little used feature of earlier versions of Access that allowed you to create an OLEDB connection from a users desktop copy of Microsoft Access to a back end SQL Server.

This allowed you to give end users the ability to interact with and edit data in a SQL Server database without requiring that they learn a new client UI, and also without requiring that you build a web facing CRUD interface to expose the data.

During the course of my day-to-day, I needed to work with a department that had previously relied on Access Data Project files to manipulate their SQL Server data.   Embedded below are the instructions that I created for them (with some minor redactions of information specific only to that department) that show how you can use Access 2013 to accomplish basically the same thing by coming at the problem a slightly different way.   Hopefully someone will find the information helpful.

If you’d prefer, you can download a copy of the PDF as well.


Migrating from Sharepoint 2010 to Sharepoint 2013

Having just completed a multiple web application migration from Sharepoint 2010 to Sharepoint 2013 (and to pat myself on the back, having done so with a total of less than 10 minutes of down time in either environment) I thought I would share the process that worked most effectively for me.  Hopefully some other poor soul having to go through this exercise will find it useful.  If it saves you any significant amount of time, consider hitting the donate button on the right.  🙂

Step One – Backup and Restore Sharepoint Content Databases

Back up any existing content databases associated with the web application you want to migrate.

  1. Open SQL Server Management Studio on a system with access to the SQL Server running your Sharepoint 2010 Content Database
  2. Find the database(s) associated with the web application you are migrating.  If you’re unsure which content database is associated with a specific web application, you can find out by visiting Central Administration on your Sharepoint 2010 server and navigating to “Databases>Manage Content Databases”
  3. Once you know the databases you want to migrate, back up each database using SQL Server Management Studio.  I find it easiest to back them up to disk in a location that is accessible to both the Sharepoint 2010 and 2013 servers to make the backup/restore process as simple as possible.
  4. Repeat the database backup process for each content database associated with the web application you’re migrating.  Another tip is to segregate each web application and treat it as its own migration if you have multiple web applications.  This makes it easier to troubleshoot and deal with any issues that come up during the migration process.
  5. Once all of your database backups are completed, restore each – one at a time – to the Sharepoint 2013 SQL Server instance.

Step Two – Create new matching web application in your Sharepoint 2013 Environment and mount content database

  1. Using the Sharepoint 2010 environment as a guideline, create a new web application in your 2013 envrionment that matches as closely as possible (settings, port number) the Sharepoint 2010 web application.  Don’t worry that the internal host name is different at this time.  There is also no need to worry if the app isn’t on the port you’d like in the 2013 environment at this time – we can change that later in the process.
  2. After you’ve succesfully restored all content databases to your 2013 environment, you’ll want to mount each content database to the web application you created in step 1.
  3. Open a Sharepoint Powershell Management console (make sure to start the console as an Administrator on the 2013 server) and use the following command to mount the content datbase:
    1. Mount-SPContentDatabase “MyDatabase” -DatabaseServer “MyServer” -WebApplication http://sitename
  4. Repeat step 3 for each Content Database that should be associated with this web application in your new 2013 environment.

Step Three – Migrate site collection users/permissions

  1. Still in an Administrative Sharepoint Powershell console, enter the following commands, one line at a time, to migrate the site collection users and permissions for this web application.
    1. $wa = get-SPWebApplication $WebAppName
    2. $wa.MigrateUsers($true)
    3. $wa.ProvisionGlobally()

Step Four – Convert your web application to claims based authentication

Applications in Sharepoint 2013 take advantage of claims based authentication.  “Classic” web applications (the default in Sharepoint 2010) are now deprecated.  While your web application will continue to function after migration without this step, you’ll run in to issues if you wish to later utilize Office Web Apps or other services in the 2013 environment that take advantage of Claims Based Authentication.

To prevent those issues, we will concert the web application to Claims Based Authentication in our new environment.

To do that, still in an Administrative Sharepoint Powershell Console, enter the following command:

Convert-SPWebApplication -Identity “https://yourwebappurl” -To Claims – RetainPermissions [-Force]

At this point, you should be able to browse to your web application and confirm that both the content and user/user permissions have migrated successfully.

There are other steps you’ll want to take to insure seamless functionality between environments depending on the services you’re utilizing or intend to utilize.  Each of these seperate steps is better covered by other articles on the web – but as a point of reference, the additional steps I needed to take in my environment included:

  1. Migration of the Business Data Catalog and Secure Store Service
  2. Migration of External Content type definitions for specific site collections
  3. Setup and configuration of the Office Web Apps server associated with the Sharepoint 2013 environment
  4. Setup of an app catalog domain, and Sharepoint Store app catalogs and app URLs

Good luck, and please leave any feedback in the comments.



Automatically insert Google Analytics tracking code as an outbound IIS rule


Google Analytics is a wonderful tool for tracking the behavior of visitors to a web site, but one of the things that has always been challenging for site administrators is finding a way to embed the javascript necessary to track visits via Google Analytics in to every page on a web server.  Google recommends strategies like providing server-side includes with the code embedded – but that will only work if every site on a server is using the same programming language or else is able to make use of the same set of server-side include files.  Often, that’s not the case.

If you’re running IIS 7 or later, you can now easily take care of Google Analytics code inclusion by creating an outbound rewrite rule via the web server. This outbound rule can make sure that the Google Analytics code gets injected on the response from your server to any requests.  This is helpful in a couple of ways.  When new sites or content is created, there’s no need to worry about modifying the sites or code itself to include Google Analytics. Additionally, because the script injection is handled as an outbound rule, it isn’t going to matter if the site being visited is .NET, PHP, or simply HTML – the web server include the tracking code regardless.

Setting Up the Rule

Step_One-3Setting up an outbound Google Analytics rule is pretty easy – but there are a couple of things to watch out for that we’ll talk about in just a moment.  First, let’s quickly step through setting up the rule.

As a first step, open up IIS Manager, and in the connections window, highlight the site that you wish to create a rule for.  Once highlighted, the features for that site should appear in the right hand side of your IIS Manager window.  In the features section, double-click on the feature labeled “URL Rewrite”.

In the “Actions” pane, click “Add Rule”, and a modal window will launch allowing you to define the type of rule that you want to create.  In this instance, we want to create an outbound rule using the blank outbound rule template found in the modal window.MUWWW03


  1. Give the outbound rule a recognizable name
  2. In the “Precondition” drop down menu, choose “Create a new precondition”
  3. Define the precondition using regular expressions, and add the variable {RESPONSE_CONTENT_TYPE} as the input, selecting “Matches the Pattern”, and then adding the value “^text/html” as the pattern to match.
  4. After saving your precondition, verify that the name you gave it is listed in the drop down list of the “Precondition” section of the rule that you’re creating.  If not, select it before continuing.
  5. In the “Match” section of rule definition, choose “Response” as the matching scope.  Leave “Match the content within” blank, and in the “Content” drop down, choose “Matches the Pattern” using “Exact Match”.
  6. In the “Pattern” section, enter “</head”>, and choose the “Ignore case” check box.
  7. Leave the “Conditions” section blank, and move on to the “Rewrite” section.
  8. Select “Rewrite” as the action type, and in the value, past the Google Analytics tracking code.   Make sure that “Stop processing of subsequent rules” is left unchecked – and save your rule.

Prepping the Tracking Code

There are just a couple of things that you’ll want to do to prepare the Google Analytics tracking code so that you can use it as a URL Rewrite rule within IIS.

First, paste the entire block of tracking code in to a text editor (I recommend BBEdit for Mac users or Sublime Text for Mac or Windows users) and remove any carriage returns/line breaks, leaving yourself with the entire block of tracking code from <script> to </script> on a single line.

Next, at the end of this single line, append </head> so that when the rule removes the initial </head> tag and injects the tracking code instead, the </head> code is replaced after injection.

Finally, as a last step, IIS has trouble interpreting left curly braces as a part of URL Rewrite rule syntax.  The Google Analytics tracking code uses the left curly brace by default in almost all of its iterations – so you’ll need to manually inspect the tracking code in your text editor, and replace any instance of “{” with “{UrlDecode:%7B}”.

Testing the Rule

Once you’ve finished with rule creation, click “Apply” and then check to make sure that the code is being correctly included by requesting a page on your site in a web browser.  When the page is returned, view the source of the page and make sure that the tracking code is being included in the appropriate location.

Watch Out For

  • If you find after creating the rule that you’re encountering a javascript error message along the lines of “Uncaught SyntaxError: Unexpected token….” then you’ve likely missed a left curly brace in the tracking code in your rule.  Go back and make sure that any reference to left curly braces are URLDecoded as noted in “Prepping the Tracking Code”.
  • If you run pages that make use of Adobe’s ColdFusion server, note that ColdFusion compresses outbound content, and IIS outbound rules will not work if the response is compressed since the response won’t be readable by the rule definitions. This will cause a 500 Server error on ColdFusion pages.  The best solutions I’ve been able to come up with for these sites is to disable the outbound rule on ColdFusion based sites and instead include the tracking code manually for those sites in an include file. If someone knows of a better way to solve the issue with ColdFusion pages, please let me know in the comments.




Tales from Higher Ed: CMS Choices Edition



The chart you see above represents an interest of “hype” chart of four popular content-management system choices over the last several years.

In blue, you see WordPress, red is Joomla, yellow is Drupal, and green is the less prominent “Concrete5”.  Expression Engine was charted, but it didn’t even register so I removed it.

When I joined Marshall University in February 2008, one of the first tasks I took on was selecting and then starting a phased implementation of a content management system for their web content.

The little circles that you see around July 2008 on the chart is when I proposed WordPress as our selection and we began implementation in earnest.

The “X” that you see on the chart is when, hilariously, a very prominent MU Alumnus who runs a web design company that I won’t name visited our campus and made the case that WordPress was a silly choice, and we should have standardized on Drupal.  Mmmmmkay.

Why does it matter where the product you’ve chosen is in this hype cycle?  Primarily because the more people you have using a product, and putting their minds to improving, supporting, and enhancing it, the better position you’re in to deliver the best product possible to your customers.

As we move through 2013 and in to 2014, it’s time to take a fresh look at where the market is at, where it’s headed, and planning for any changes we need to make in the products we’ve chosen and the way that we’ve deployed them so that in 2015 or 2016 we can be similarly position on a hype chart a few years later.

Part of being a good leader is having confidence in your decisions and the information you use to make them. Listen to feedback, take in to consideration criticisms, but don’t just listen to someone because of who they are or who they know. Use data to confirm the decisions you make, and constantly reevaluate and adjust based on the results of your own analysis.