Join the #CodeGeneration Movement

Building on Microsoft’s recent announcement to invest $75 million in community programs to increase access to computer science education for all youth worldwide, Microsoft Canada is launching the #codegeneration movement – to inspire Canadian youth (13 -18 year olds) to learn more about coding. #codegeneration will run from now until Computer Science Education Week (December 7-13). 

Join the Movement!

Help us spread the word and teach Canadian youth to create with technology. Anyone can code, it’s simple and easy.

  • Coding Challenges: For the next five weeks, Microsoft will be issuing coding challenges at Students who complete these weekly challenges will have the chance to win points towards prizes while learning the basics of coding; and parents and teachers can find resources to help them lead students in these challenges themselves.
  • “Hour of Code” Sessions: As a founding corporate supporter of, Microsoft is offering free Preparation Webinars with live chat for questions and answers on November 24 and December 1.  Ready to hold your own Hour of Code with your students – download your toolkit today and lead them through a Minecraft tutorial.  Or schedule a field trip to a local Microsoft Retail Stores during Computer Science Education Week to give young developers the opportunity to learn coding. For more info, please visit the In-Store event section at a store near you.

Spread the word!

Nintex Upgrade / Install Failure – SecurityException

If you are upgrading or installing Nintex (and, as you will learn, pretty much any other .NET app/solution/web part/widget etc.) you may run into a fail whale in the form of the the error described on this post on the Nintex Forums

“Trying to upgrade my PRODUCTION server to the latest build of Nintex WF 1.11.1

At the end of the upgrade process I get a Windows Command prompt window with the following text:

Upgrading solution package…
System.Security.SecurityException: Access denied.
at Microsoft.SharePoint.Administration.SPSolutionLanguagePack.CheckPermissionJobScheduled()
at Microsoft.SharePoint.Administration.SPSolutionLanguagePack.UpgradeCabFile(String path)
at Microsoft.SharePoint.Administration.SPSolutionLanguagePack.Upgrade(Stringpath, DateTime dt)
at Microsoft.SharePoint.Administration.SPSolution.Upgrade(String path, DateTime dt)
at Nintex.Installer.WSSHelper.Program.DeployWSP(String[] args)
The Zone of the assembly that failed was:
Press any key to continue…

While the advice offered in that thread regarding using MSIEXEC works, it’s important that one understands the simple cause and effect for this issue : one needs to Right-Click on the file in Windows Explorer and “Unblock” it before attempting to execute it. This also is a simple remedy for preventing similar issues with lot’s of .NET related installables, .DLLs, solutions etc.

You simply need to “Unblock” the installable file to prevent this situation from occuring – it is common for UAC in Windows to block executable or compilable code downloaded from the Internet Zone. Unless you explicitly unblock it, this type of error will occur. Had the MSI or file/code/.DLL been copied/compiled/executed locally in Visual Studio/via the installer etc. , the newly generated .dll or unpacked program files would have been in the same Zone (the My Computer Zone) as the rest of the .Net assemblies for the web application. The problem would not occur.

You will often encounter warnings when downloading the files (note: these warnings are not exclusive to .MSI or .CHM installer file types but also can occur for .ZIP’s, .DLL’s and other formats):

The Nitty Gritty Details

This file / directory blocking is provided by default on:

Windows XP SP2 with IE 7
Later Windows, like Windows Vista, 7

And marking the file / directory as blocked / unblocked is implemented via alternative data stream feature, which is a feature of NTFS file system. The alternative data streams are just some data like key-value pairs attached on a file or folder.
In the above scenarios, since the file in this scenario was downloaded from an internet location, the file is marked by set such key-value pair:

key (data stream name): Zone.Identifier;
value (data stream content): [ZoneTransfer]


1 = trusted;
2 = intranet;
3 = Internet;
4 = untrusted.

The above alternative data stream can be examined via command line:

more <

That is how is file marked as blocked to enhance the security, and a “Unblock” button appears on the property dialog.
Actually any file / directory marked with this Zone.Identifier alternative data stream is considered from Internet and blocked by the Windows. A test.txt file can be created to test this:

echo test > test.txt

by checking its property, this test.txt is unblocked of course. Now inject the same Zone.Identifier alternative data stream into test.txt:

more < > test.txt:Zone.Identifier

By clicking the “Unblock” button, the key-value pair is removed from the file, so the file is treated as unblocked by Windows.

If the files in the are extracted without unblocking the, those file will also have the same alternative data stream, indicating they are from Internet. So they are blocked, just like the above test file.

Resolution 1 – The Just get this damn app working approach

1. Roll back your code changes – this means uninstall any new .DLL’s, solutions, components that you may have added, or cancel out of the MSI install routine you were attempting.
2. Ensure that any new .DLL’s/code/files that are applied by the change are unblocked (right click on the file in Windows Explorer and click unblock). If you have one .ZIP file with a bunch of .DLL’s and other code inside it, it’s only necessary to unblock the root .ZIP file itself.
3. Re-apply code changes
4. If Application doesn’t come back to life give IIS a kick in the head with an IISRESET.exe

Resolution 2 – Change Workstation Config So Files Don’t Get Blocked Like this In Future

Several ways can be used to remove the Zone.Identifier data stream to unblock file / directory:

-Configure Windows to disable this feature (described below)

-Use command lines
-Use streams.exe provided in Sysinternals Suite (technique described here)
-Programmatically remove the data stream
-Registry Tweak to take ownership of a folder (technique described here)

Please review the following links that explain why this security exception is occurring

In completely unrelated news, it’s Yalla, the underwater cat: