DotNetNuke can’t upgrade as Host Login does not work

DotNetNuke Upgrade Fails. Cannot login with Host.

If you are trying to upgrade your DotNetNuke site and found that you are presented with the Welcome to the DotNetNuke Upgrade Page, but can’t login with your Host (SuperUser) account.

image

DotNetNuke Upgrade – Version 06.02.07

Current Version – 06.02.05

Welcome to the DotNetNuke Upgrade Page.

The first step is to choose the language you wish to use for the Upgrade.

You are about to upgrade your website to a more recent version of the DotNetNuke application. Applying upgrades on a consistent basis is the best way to ensure that you are protecting the integrity of your investment and the security of your users and assets. Before proceeding with the automated upgrade process please ensure that:

  • you have made plans to first attempt this process in a staging environment
  • you have documented your current installation characteristics including doing research on the compatibility of any third party modules which you may be using
  • you have created the necessary backups of your environment so that you will be able to restore your website in the event of an unexpected upgrade failure.

Solution

Just simply close your browsers, or better yet, grab a browser that you have not accessed for some time. Then try hitting your URL and loggin in with the new browser session. While I did not bother to work out what the cache issue was, I did find it was cache related to an open browser session that was trying to authenticate to a previous session.

Easy when you know how~!

.zip files from Mac OS show up as green/encrypted

Green files and folders on Windows 7 indicate they are encrypted.

Usually this is a function of a program that will make these files encrypted for a reason. Security is usually the reason. But…

An interesting little bug in the process of creating a .zip file on a mac and moving it over to a Windows computer.

When a .zip file is created according to standards for .zip files found here:

http://www.pkware.com/documents/casestudies/APPNOTE.TXT

They specify that .zip archives include a tag informing about itself to the program trying to decompress the archive. This tag information is known as the “version made by” and as the name suggest, it would tag information about the program version of .zip and the files system in use.

 0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems)
          1 - Amiga                     2 - OpenVMS
          3 - UNIX                      4 - VM/CMS
          5 - Atari ST                  6 - OS/2 H.P.F.S.
          7 - Macintosh                 8 - Z-System
          9 - CP/M                     10 - Windows NTFS
         11 - MVS (OS/390 - Z/OS)      12 - VSE
         13 - Acorn Risc               14 - VFAT
         15 - alternate MVS            16 - BeOS
         17 - Tandem                   18 - OS/400
         19 - OS/X (Darwin)            20 thru 255 - unused

When the Mac system encrypts the files, it marks them with the attribute of being UNIX based files. Correct considering the Mac operating system is based on UNIX.

The problem arises at the Windows end. Because Windows is created by the most arrogant computer company in the world, it does not recognise that a .zip file could have been created with a computer that is not running Windows. It fails to correctly see the flag as UNIX and marks the files as Encrypted.

Leaving Files Encrypted

If the files are left as encrypted, you may find that there are problems if the files are shred on a network drive etc. Taking ownership will not change this flag, and resetting permissions does nothing.

The Easy Fix – Remove Encrypted Tag

Removing the incorrect Encrypted Flag on a green file in Windows 7, or Windows Server is really easy. Right click the file or files (holding the shift key to select multiple folders and files) then Click: Properties / Advanced / Un-tick the Encrypted Option

 

That’s about it. All fixed.