Moving Nintex Workflow to a new site

As stated in an earlier blog my team was tasked with creating a SharePoint staging environment that mirrored production. Part of the SharePoint site included Nintex workflows. This did not go as smoothly as I had thought, either. Even though central admin indicated that the connection to the database had been established, whenever I tried to view my existing workflows in the SharePoint site I would see the following message: Failed to open a connection to the Nintex Workflow configuration database.
System.Data.SqlClient.SqlException: Cannot open database "" requested by the login. The login failed. Login failed for user ''.

I stumbled upon this thread on the Nintex site which pointed me to the resolution. The appPool user account needed: 1) permissions to the Nintex database; 2) to be added to the role WSS_Content_Application_Pools

reason #312 why I hate SharePoint

I know, everyone has many reasons to hate SharePoint, and they are all valid. So, this is really just another in a long stream, but I wanted to share it any way.

We were tasked to create a staging environment which mirrored production. Sounds simple, right? Wrong. The first naive step was to create a site collection backup of production. Getting it onto the staging environment proved painful enough due to its size, but after it was finally uploaded I thought we were home free. The restore failed... repeatedly... miserably. The error message that displayed was: "The site collection could not be restored. If this problem persists, please make sure the content databases are available and have sufficient free space." I tried increasing the database size. I freed up room on the hard disk. I created a blank SharePoint site and tried to restore into that since every time I ran the restore into the existing SharePoint site the database just kept getting bigger, bigger than the production database, even though I was specifying "overwrite".

After happening upon a post where a restore was generating the same error message I noticed one responder said to can the whole site collection restore notion and just do a backup/restore of the content database.

I did it, it worked. W00T! It's not complete in that we still have to manually get the customizations back into the site, but it at least got us about 85% - 90% there.

Another reason VB.Net is inferior to C#

A while back I developed a custom module in DNN for a client. Due to my desire to type as little as possible I used the letters from the client's name to create the namespace -- ASC. We had been running DNN 4.8 and all seemed fine until I was told to upgrade to 5.1 Somewhere along the line the DNN core code had been modified to make a call to a VB.Net method Asc. Since VB.Net is *NOT* case sensitive like C# this caused a host of problems - mainly, the site would not load and there was no kind error message informing me as to what had happened.

After rewriting and redeploying my DLL to use a different namespace all was right with the world, but I wasn't happy.

DNN and Fallback Skin Doctype

Recently I was required to upgrade a customer's DNN site from 4.8 to 5.0. Simple enough, right?
1) Copy site folder to another location
2) backup database
3) extract the contents of the upgrade zip file into the site folder
4) navigate to http://SITEURL/install/install.aspx?mode=install
5) VOILA! Upgrade complete

Unfortunately, after doing the upgrade the customer's dropdown menus were no longer appearing on top of the content (we had used CISS.SideMenu for the menuing system) . Upgrading the menu module only made things worse - the menu bar disappeared altogether. So, I reverted back to the 4.8 site and went about replicating their environment on a VM.

Thinking that maybe the problem was DNN 5.0 I decided to go straight to DNN 5.1. The upgrade was successful and in the process I was able to resolve another problem the customer was having - the dropdown menus look garbled in IE 8 unless the site was run in compatability mode. I was stoked and ready to tackle the production server again.

Much to my dismay, after the second upgrade went seamlessly, the same problem appeared. I was ready to throw in the towel. Thanks to a kind co-worker who jogged my memory I was able to resolve the problem.

I had changed the Fallback Skin Doctype on the portal settings screen to XHTML 1.0 transitional on my VM AND on the production server BEFORE doing the upgrade (http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryId/2130/The-Fallback-Skin-Doctype-and-skinning.aspx). This had been done in an attempt to resolve the IE 8 issue. Unfortunately, the upgrade to 5.1 wiped out this setting. Once I changed it back the menus appeared just fine.