Adding style and Google Analytics to an Apache directory index (mod_autoindex)

I recently had to spruce up a password-protected Apache directory index site that is being used to host some files for download.

In addition to making it look more presentable, I also discovered that you can inject code into the <head> of the index page. This allowed me to achieve what I’d wanted to do for a while on that site – track visitors using Google Analytics.

To do so you already need to be using indexes and FancyIndexing. Then, simply add the following to your .htaccess file:

IndexHeadInsert "<script type=\"text/javascript\">var _gaq = _gaq || [];_gaq.push(['_setAccount', '{INSERT TRACKING CODE HERE}']);_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>"

Here’s the rest of my .htaccess file, excluding the security section:

Options +Indexes

IndexOptions +FancyIndexing
IndexOptions +FoldersFirst
IndexOptions +XHTML
IndexOptions +HTMLTable
IndexOptions +SuppressRules
IndexOptions +NameWidth=*
IndexOptions +SuppressDescription

IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t /resources /cgi-bin

IndexStyleSheet "/resources/style.css"

IndexHeadInsert "<script type=\"text/javascript\">var _gaq = _gaq || [];_gaq.push(['_setAccount', '{INSERT TRACKING CODE HERE}']);_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>"

Native resolution not set after deploying via MDT 2010

If your machines aren’t automatically having their display resolution set to their monitor’s native resolution after deployment via MDT, this may be the cause of the problem.

Although I’d previously deployed Vista and Windows 7 using MDT 2010, I’d never seen this problem. The issue occurred with a captured HP ProBook x86 Windows 7 Professional build.

I had to edit the unattend.xml for the task sequence in question, and delete the Display section from oobeSystem –> x86_Microsoft-Windows-Shell-Setup_neutral. Once this was done, the strange default of 1024 x 768 (where did that come from?) was no longer applied, and Windows Setup detected and set the maximum resolution.

WSIM-res_issue

MDT/WSIM fails to catalog a captured Windows 7 image

Had an issue today where I was trying to catalog a captured Windows 7 WIM image, both through MDT 2010 and through WSIM directly.

Doing so comes up with an error:

Performing operation "generate" on Target "Catalog".
The operation failed to complete.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentNullException: String reference not set to an instance of a String.
Parameter name: source
   at System.Globalization.CompareInfo.IsPrefix(String source, String prefix, CompareOptions options)
   at ?A0xfe36268f.ConvertToNtPath(String path)
   at Microsoft.ComponentStudio.ComponentPlatformInterface.CbsSessionAdaptor..ctor(String bootDrive, String imageWinDir, String servicingPath)
   at Microsoft.ComponentStudio.ComponentPlatformInterface.OfflineImageImpl.InitializePackages()
   at Microsoft.ComponentStudio.ComponentPlatformInterface.OfflineImageImpl..ctor(OfflineImageInfo imageInfo)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at Microsoft.ComponentStudio.ComponentPlatformInterface.Cpi.PlatformImplementation.CreateOfflineImageInstance(OfflineImageInfo imageInfo)

2012-01-06 11-55-50_DeploymentWorkbench - [Deployment Workbench_Deployment Shares_Sydney MDT Deploym

The captured image I was trying to work with was of a 32-bit machine, and the WAIK tools I have installed on my desktop are the 64-bit ones.

The solution, as I learned here after a bit of searching, is to re-run the catalog operation on an x86 machine.

As you can’t install the 32-bit tools on a 64-bit machine, I installed the 32-bit tools on my laptop, fired up WSIM, opened the WIM image, re-ran the catalog operation, and it succeeded without errors.

You’d think that they could catch the exception and give you a useful message about running the catalog again on a compatible machine, but no…