Blog post of extremely limited usefulness – ColdFusion 11, Mac OS X and MAMP

This post will admittedly have a very small audience, but for those of you who do stumble on to it while trying to get ColdFusion 11 installed and configured in a development environment on OS X using MAMP, you’ll hopefully find it very helpful.

By default, the web server connectors that ship with ColdFusion 11 (including the Apache connector for OS X) don’t play nicely with a MAMP setup. Attempting to run the connectors in their default state will result in the connector scripts trying to install themselves in to the default OS X apache installation in the /etc/apache2 directory.

Of course, with MAMP, what you’d like is for the connector to install itself to the Apache webserver embedded within MAMP, which on a default MAMP OS X installation is located within the /Applications/MAMP directory.

The easiest way to resolve the problem is by opening up the script (this is located in the /Applications/ColdFusion 11/cfusion/bin/connectors directory) and modifying it so that the -dir, -bin, and -script variables point to the Apache installation that you want to use with ColdFusion.

You can do this pretty easily yourself with any code editor, but in the event that you can’t or don’t want to do this, I’m sharing a pre-modified version of the script that you can download and run to get your installation up and running.

You can download the modified web server connector script here.

Read More


Multi-factor Authentication Is Simple Enough Now That Everyone Should Be Using It

Multi-factor Authentication (also sometimes called Two-Factor authentication) is a method provided by many sites and services to help their users better secure access to their accounts.  For the remainder of this post, I’ll use MFA for short.

Most major web services now offer some sort of MFA, and over the last several years, integrating the use of MFA in to your daily life has become simple enough that it should be accessible to most every user.

So much of our lives is online these days, that most of us have a lot of personal, private information stored with our email service providers, in our Dropbox folder, Google Drive, SkyDrive, etc.  Imagine if someone had the password to your email account.   What types of information might they be able to find out about you?  If it doesn’t give you a little cause for concern it should.   Yet for many people, those sites and services are protected only with a password – one of the weakest forms of security available to end users.

Even if you have good personal security habits, and make use of strong passwords that are regularly changed and never written down, it is still possible to pretty easily circumvent that security measure with the right tools, a little time, and a lot of persistence.  Unfortunately, the vast majority of users don’t have good personal security habits.

According to a study conducted by Time Magazine in January 2014, the most popular passwords that people selected to protect their information online were “123456”, “iloveyou”, and “qwerty”.  Ahem…..

Needless to say, those passwords aren’t indicative of good personal security habits at all. It’s roughly akin to leaving your wallet laying on the drivers seat of your car in plain view, with the window rolled up and the car door locked. Yes, you’ve put forth a minimal amount of effort to protect yourself, but it’s not going to discourage someone who is even marginally determined.

Are you responsible with maintaining security of the network in a workplace?  If so, the risk is even greater for you. According to a 2013 Verizon Data Breach Investigations report, 76% of network intrusions exploited weak or stolen login credentials.  In these incidences, the companies suffering the breach weren’t even really trying to make it difficult for their networks to be exploited. The tools needed to exploit passwords like “123456” aren’t sophisticated, and can be downloaded and run for free by anyone, of any age, with access to a working internet connection.

A good password should be your first line of defense in protecting your or your organizational data.  Sometimes the password policies of organizations work against themselves by requiring things like uppercase letters, special characters, etc.  If you haven’t see the classic xkcd comic about password strength it’s worth taking a look.

The point of the xkcd comic is that in most cases, a random string of words that can be remembered easily by the user is a much better strategy against a brute force attack than the typical password gymnastics required by most organizations attempting to enforce strong password policies that may encourage users to write down their passwords and stick them to the front of the monitor.

Fortunately, in addition to having a good, difficult to guess, password, multi-factor authentication adds another significant layer of protection by combining something the user knows (a password), with something the user has (a token, often sent to a phone via SMS or through a MFA application like Google Authenticator).

The way it works is pretty straightforward. You will download an application on your phone, and pair that application with a site or service that supports MFA. Typically, the site will provide you with a QR code that you can simply scan with your phone, and the pairing will happen transparently to the user.  Once activated, when you attempt to login to that service the next time, you’ll first be asked for your password. After successfully authenticating, you’ll be asked for a security code. You will open the authenticator app on your phone, copy the randomly generated code, and provide it to the login page to complete the login process. In most cases, this randomly generated code will be automatically changed every 20-30 seconds. The entire process adds a total of 10-15 seconds to the login process, but astronomically raises the security of your accounts.

A simple example can be seen below.  In this example, I’m logging in to my RSS feed reading application using my Google account.  Note that after entering the correct password, I’m challenged for a code that I can obtain by switching over to my authenticator application.  I copy the code, switch back to the application I was logging in to, provide the code, and complete the login process. It’s a minor additional step for a major security advantage.


authyMost authenticator applications will allow you to register more than one service, so that you go to the same code generator application for all your MFA sites.  My personal preference, and recommendation, is Authy, a great MFA application available for both iOS and Android devices.  Authy allows you to register multiple MFA accounts, and easily switch between them via a familiar interface.

If you’re interested in enabling MFA for the applications that you use regularly, be sure to check the support site for the service in question. Chances are they offer some sort of MFA. If not, don’t be afraid to request that they add this option. In 2014, this really should be part of the basic service offering for any serious provider.

Here are links to the MFA options offered by some of the services that I (and probably you) use regularly.

Twitter and Apple also offer their own implementations of MFA that work in slightly different ways. In the case of Twitter, the code is sent to your phone either via SMS (my preference) or through the Twitter application itself as a message sent directly to you in-app.  For your Apple ID, a four digit pin is sent via SMS to a registered device, and required in addition to your Apple ID password. To enable 2 factor authentication on your Apple ID, sign in at, and visit “Two Step Verification” under “Password and Security”.

In summary, if you haven’t already been exposed to the concept of multi-factor authentication, the good news is that it’s now very simple and convenient to use. Hopefully the information provided here will help you make yourself more safe and secure online. Good luck!




Read More

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.


Read More

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.

Read More

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.


Read More