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.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 < MyCodeFile.zip:Zone.Identifier
That is how is MyCodeFile.zip 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 < MyCodeFile.zip:Zone.Identifier > 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 MyCodeFile.zip are extracted without unblocking the MyCodeFile.zip, 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: