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.

The Dreaded "The SSP Timer Job Distribution List Import Job was not run."

Unfortunately, when I set up some test SharePoint sites on my dev machine I tied service accounts to my network userid & pwd. Our network policy requires that passwords be changed every 90 days, so every 90 days I get into a pickle because I can't remember all that I had to do so that SharePoint would continue to play nice on my machine.

1. In IIS, change the password of all App Pools that are tied to my network account and restart IIS


2. At the DOS prompt run stsadm -o updatefarmcredentials -userlogin <domain\userid> -password <new password> followed by iisreset /noforce


3. In Central Admin:
   
   • Go to App Management and click on "Manage Search Service" under the "Search" group and change the "Office SharePoint Search Indexing and Query" account's password
   
   
   • Click on Shared Services Administration, right-click the default shared service and select Edit Properties and update the password for the SSP Service Credentials


4. At the DOS prompt run iisreset /noforce

How to Show/Hide SharePoint QuickLaunch

The bulk of this comes from http://suguk.org/blogs/sharepointhack/archive/2008/01/29/8093.aspx

Insert the following JavaScript block immediately before the </Head> tag in your master page:


<!--
function showhide(layer_ref)
{
var state = 'block';

var tbl = document.getElementById(layer_ref);
var img = document.getElementById("img" + layer_ref);

if (tbl.style.display == 'block')
{
tbl.style.display = 'none';
img.src = "_layouts/images/BLK_RGT.GIF";
}
else
{
tbl.style.display = 'block';
img.src = "_layouts/images/BLK_LEFT.GIF";
}
}
//-->
</script>

I put the following div immediately inside the TD with ID LeftNavigationAreaCell:
<div id="divOuterQuickLaunch" style="display:block;">

I added the following immediately after the ContentPlaceHolder PlaceHolderTitleAreaSeparator:

<tr>
<td style="text-align:right;">
<a id="lnkregionalNav" style="cursor:hand" onclick="showhide('divOuterQuickLaunch');">
<img src="_layouts/images/BLK_LEFT.GIF" id="imgdivOuterQuickLaunch" alt="Show/Hide Quicklaunch"/>
</a>
</td>
</tr>


If you are looking at a list, the behavior will not be as expected as there is an image at the top of the page that prohibits the quicklaunch area from collapsing when hidden. To correct this, find the ContentPlaceHolder PlaceHolderPageImage and add Visible=”false”

That should do it.

How To: Associate a K2[blackpearl] SmartObject with a SharePoint list

This PDF describes how to associate a K2[blackpearl] SmartObject with a SharePoint list:

How To Associate a K2[blackpearl] SmartObject with a SharePoint list