fooshen's

The Form has been closed. Or has it?

Developing with forms services, especially with Workflow; usually turns out to be a love-hate affair - it has enough twists and turns to put a bag of pretzels to shame. One of the most frustrating errors (gauged from the amount of "help needed!" posts in newsgroups) - the infamous "The Form has been closed" message, usually occurs to Workflow association, Initiation, or task modification forms. Upon closer inspection in SharePoint's log files, the most common message is:

"The specified form cannot be found".

If the workflow host (in this case, SharePoint) could not see your wickedly awesome form that you have spent the entire week developing, the first place to check is the worfklow xml file (workflow.xml, by default). We have all checked, double-checked, triple-checked the form URNs that was supposed to be the guy who will tell SharePoint how to locate our forms that has been uploaded from our workflow feature, but still it could not locate the forms!

One item of note is that we have to understand the difference when we "Save" a form template, and when we "Publish" them. Note that if you publish the form under a different name from the one that was saved, the Form URN is different between them. The URN that we need to specify should be the one that we publish.

Here's an illustration:

I created a form, and save it as "Test" in C:\. Subsequently, I published it as "Test Form" in C:\ again.

The Form URN for the saved form (if I did not close my InfoPath designer, and view the ID, this is what I will get):

And if I open the published form from C:\Test Form.xsn, this is the correct ID:

Cross check that against your workflow.xml, and you should have it ironed-out in no time :)

Additional tips: After deploying the workflow feature, you can find all the workflow-related forms uploaded from your Central Administration, Application Management, Manage Form Tempates -> Click on the form in question and view its properties. That will reveal the ID that will be "seen" by SharePoint.

If all else fails, here is a sure-fire way to determine your form's URN: rename the published form to .cab, double-click to open it. Extract the file manifest.xsf and open in notepad. Locate the xsf:xDocumentClass element that should be right at the top, and check the "name" attribute. This is your form's URN.

SharePoint Development - Quick Tips #1

For SharePoint developers, we will visit the "12" hive almost on a daily basis - to deploy features, check log files, deploy custom site definitions, etc. One old trick is to create an environment variable that short-cuts our way to the "12" hive (alternately, most of us would have a shortcut already created on the desktop or the explorer's quick launch).

From "My Computer", right-click and select "Properties" (or, "Win+Break" - another short-cut). From the "Advanced" tab, select "Environment Variables". Click on "New", and enter a new environment variable:

Notice that I've also used another variable in this variable: "%programfiles%". After saving the variable, we can now easily navigate to the "12" hive from windows explorer simply by typing "%moss%". This applies to the command shell as well.

While at it, we can also add the "bin" folder of our "12" hive into the PATH variable. Now, from the command shell, we could run "stsadm" from any path :) Shaves off a couple of miliseconds, but it does add-up.

Installing SharePoint without AD?

Update: Judging from the comments I've received, no doubt many has tried this path - however it is IMPORTANT to note that this is NOT A SUPPORTED deployment. Using non-domain account for installing and configuring SharePoint will result in ending up with only ONE web server and ONE database - that's it - NO splitting of roles in the WFE, and NO redundency support, and you CAN'T add more servers. 

There has been tons of posts about using Form-based authentication for MOSS (almost all of them are on using the ASP.Net SqlMembership provider). That is really a great improvement over SPS2003. Recently I was helping a customer who had the challenge of deploying MOSS, not just with form-based authentication, but also to deploy SharePoint farm on an SQL server which is not a member of an AD domain.

At first glance, this may not seem possible - the configuration wizard for setting up the configuration database expects a domain account to connect to the database server (workgroup account will work fine if the entire farm is on one single box) - which is not good if we want to use SQL authentication.

Now, here's one of the reason why the SharePoint installation wizard has a checkbox prior to running the configuration wizard:

Right after installation, uncheck this checkbox, or if you did and were halted at the "Specify Configuration Database Settings" page, simply close the wizard. What we need to do now is to go to our SQL Management Studio (or SQL Enterprise Manager for SQL2K), and create four databases manually. Make sure these databases are created with the Latin1_General_CI_AS_KS_WS collation (for the curious, C = Case, A = Accent, K = Kana, W = width, and I/S for Insensitive/Sensitive). These four databases would be: the SharePoint Configuration, SharePoint Admin Contents, Shared Services, and Shared Services Search. Assign the SQL login that we are going to use for MOSS as the dbo for these four databases - let's name them as "SharePoint_Config", "SharePoint_AdminContent", "SharedServices_DB" and "SharedServicesSearch_DB".

Now fire up the command line console and use the following command (from the 12 hive* folder, "bin"):
*12 hive being the %programfiles%\common files\blah blah blah\12 - you get the idea.

PSConfig -cmd -configdb -create -server database_servername -database SharePoint_Config -user domain/username -password password
-dbuser sharepoint_login_username -dbpassword sharepoint_login_password -admincontentdatabase SharePoint_AdminContent

The arguments for:

server - this would be your SQL Database Server's Instance name
database - the database name for SharePoint's configuration (we name it SharePoint_Config here)
user - the windows account used as the server farm's administrator account
dbuser - the SQL login account to connect to the database
admincontentdatabase - the database name for SharePoint's Central Administration site (SharePoint_AdminContent)

Most importantly here are the dbuser and dbuserpassword arguments. These are not available from the configuration wizard UI.

Running the PSConfig command:

Now, we are ready to resume the configuration wizard. Re-start the wizard from the start menu (Start -> Programs -> Office Server -> SharePoint Configuration Wizard...). The configuration wizard is smart enough to detect that we already have the configuration database created:

Unless we want to recreate the databases again, choose not to disconnect from the server farm. Follow the wizard on as per usual installation. Now when it comes to configuring the farm's services, we can easily configure it to use SQL Authentication:

Ditto for every subsequent content databases that the wizard will need to create for every site in our Farm. Now when it comes to setting up the SSP, simply point the database to the ones that were manually created earlier, and supply the SQL Authentication credentials as well.

So, it's actually possible, and quite easy in fact (once you have figured out the command parameters!) to deploy MOSS that connects to SQL using SQL logins! One BIG caveat with this though: We will be limited to ONLY ONE topology, which is 1 MOSS box, and 1 SQL box. That's it - no farms. Not scalable, but not impossible either.

Throttling SharePoint 2007 Logs

If you have ever developed on SharePoint, there's gotta be at least once when you came across the superbly detailed error message:

"Unknown error" ...and its likes.

That's when we have to start ploughing through the humungous amount of log entries in "%programfiles%\Common Files\Microsoft Shared\Web Server Extensions\12\Logs". Well, but there's an easier way - the log files doesn't have to be humungous!

We can throttle the log file outputs, depending on which area of SharePoint that we are working on. From the SharePoint Central Administration, navigate to Operations and Diagnostic Logging.

Turn off every type of log entries by setting the trace log entry to "None" for "All" categories.

When I'm working with MOSS workflow, I'll set the log entries to "Unexpected" for "Workflow Infrastructure". If I'm working with Forms Services as well, then I'll do the same for Form Services.

We can also set the number of log files to a smaller number, for a shorter period of time. Typically I will have 5 log files, each log files recording up to 5 minutes of activities.

Smaller, fewer log files - with throttled verbosity; translates to faster debugging - and I do suspect there's also a slight performance advantage, without all the unnecessary messages logged :)

Writing WSS2.0 WebParts using Visual Studio 2005

Problem statement:

Your corporate intranet portal/site is using Sharepoint Portal Server 2003 / Windows Sharepoint Services 2.0. You are mulling over whether to have Visual Studio .Net 2003 or the newer, cooler, and definately awesome Visual Studio 2005 as your corporate development tool of choice. You also want to make sure that you can develop webparts for SPS 2003/WSS2.0 using the same IDE.

Tough choice? It's really simple.

Here's how:

1.) Ditch Sharepoint Portal Server 2003. Upgrade to the latest, baddest kick-ass portal in town, SharePoint Server 2007. Go with Visual Studio 2005, and you will attain unparalleled awesome-ness.

2.) If you MUST develop for SharePoint Portal Server 2003 with Visual Studio 2005 - see #1 above.

Ok, seriously. Building web parts for SPS 2003/WSS2.0 using Visual Studio 2005, and you will undoubtedly venture into the problem area where you would want to use VS 2005 to build for .Net 1.1 runtime.

Enter MSBuild, the Microsoft Build Engine for Visual Studio / .Net platform. All it takes is some target specifications to direct MSBuild to build for .Net 1.1 runtime. Sounds easy? Not.

Unless you have MSBee, which will provide us some pre-defined target files to use with MSBuild. To install MSBee, make sure you have all the pre-requisites already installed (as noted in its download page).

Now we are ready to build a webpart on .Net 1.1. Since we don't have any Web Part templates for SPS2003/WSS2.0 in Visual Studio 2005, we will start off with a plain old Class Library project.

First thing to do is to add a reference to Microsoft.Sharepoint.dll assembly from C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\ISAPI\

Add the "using" redirectives for Microsoft.Sharepoint, and remove the default System.Collections.Generic - we don't have generics in .Net 1.1.

Example:

using System;
using System.Text;
using Microsoft.SharePoint.WebPartPages;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Reflection;

namespace SharePoint2003WebPart
{
    public class MyWebPart: WebPart
    {
        protected override void CreateChildControls()
        {
            Label message = new Label();
            message.Text = "CLR Version: " + Assembly.GetExecutingAssembly().ImageRuntimeVersion;
            this.Controls.Add(message);
        }
    }
}

Next, open the .csproj file, and add the following import statements into it:

Add a reference path to the project so that MSBuild can locate our Microsoft.SharePoint.dll assembly:

Provide a strong name key and we're ready. We have to sign it the old-fashioned VS.Net 2003 way - use "sn -k yourfile.snk" and adding the attribute [assembly: AssemblyKeyFile(../../yourfile.snk")] into AssemblyInfo.cs.

Now we are ready to MSBee it. From the Visual Studio command prompt, use the following command line:

msbuild {your csproj file} /p:TargetFX1_1=true

Almost there now... Grab the assembly under the bin\FX1_1\debug (or release) folder, (instead of \bin\debug) and drop it into the Global Assembly Cache. 

For SPS2003/WSS2.0 webparts, we need to create a corresponding .dwp file, contrasting to the self-reflected .webpart file in MOSS. In Visual Studio 2005, add a new xml file and name it anything with .dwp extension. Get the PublicKeyToken value from the GAC, or use the -T command line switch with the Strong Name utility: sn -T assemblyName.

<?xml version="1.0"?>
<WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
   <Assembly>AssemblyName(with no .dll extension), Version=VersionNumber, Culture=Culture, PublicKeyToken=PublicKeyToken</Assembly>
   <TypeName>WebPartNamespace.WebPartClassName</TypeName>
   <Title>DefaultWebPartTitle</Title>
   <Description>WebPartDescription</Description>
</WebPart> 

From SPS2003/WSS2.0 site, import the newly created dwp file, and we're done!

Can it be better? You bet.

Right-click on your Visual Studio 2005 menu bar, and select Customize (waaay down below). On the Commands tab, select "Rearrange Commands". Select "Add" and choose "File" and then "Export Template" from the Commands selection.

When done, the new "Export Template" command will be available from the "File" menu. What this do is to take the existing SharePoint2003WebPart project and convert it into a Project template with all the project import targets and references intact, and the .dwp file is included as well.

Enabling Digital Signatures in InfoPath forms created from pre-defined schemas

Recently I was working on some InfoPath samples for United Nation's Electronic Documents standards (UNeDOCs: http://www.unece.org/etrades/unedocs/), and one of the key requirements I am looking at with InfoPath is the ability to digitally sign the form. Sounds like a no-brainer, since this feature is given with InfoPath.

However, after I happily imported the schema into InfoPath and attempted to enable digital signature:

Ok, so InfoPath didn't allow me to enable digital signatures. What's wrong with my xsd?
A little click on the least-clicked button in InfoPath (that's the little [?] help button) and a quick search on "Digital Signature" reveals:

Take note of the... well, NOTE. "If a form template was designed based on an XML Schema, you can enable digital signatures for the form template only if the XML Schema has a node that is in the W3C Xml digital signature namespace". Well, that's compliance for you.

So, using the all-powerfull killer app (that's NOTEPAD.exe), I open the xsd file and added a new element for my digital signature and point it to the W3C digital signature namespace: http://www.w3.org/2000/09/xmldsig#
as such:

<xsd:element name="DigitalSignature">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:any minOccurs="0" maxOccurs="unbounded" namespace="http://www.w3.org/2000/09/xmldsig#" processContents="lax"/>    
   </xsd:sequence>
  </xsd:complexType>
</xsd:element>

Source: http://www.w3.org/TR/xmldsig-core/#sec-Versions

Voila, now InfoPath allows digital signatures on my form!

Forms not working after applying B2 Technical Refresh update

You have just applied the Beta 2 Technical Refresh to your SharePoint farms, and everything look to be in working order. And then, when you try to open a form to submit for your workflow, Forms Server just wouldn't let it be. But, it works before the TR, and you swore you have not done anything to it after the TR patch.

What happened here?

It's pretty straight-forward. You will need to run stsadm -o reconvertallformtemplates after applying TR, because it says so in the installation guide, step #10 in the "How to upgrade an existing Beta 2 installation to Beta 2 Technical Refresh" section.

For those who jumps straight into installation without much of a glance at the readmes and guides and important!readme!first!'s, here's two very important links:

1. The official guide on Installing Microsoft Office SharePoint Server 2007 for Beta 2 Technical Refresh: http://technet2.microsoft.com/Office/en-us/library/f49862ab-e067-4723-bb90-7eb1182c65ce1033.mspx?mfr=true

2. List of known issues, AND the available workarounds: http://officebeta.iponet.net/en-us/products/FX101517541033.aspx?ofcresset=1

SharePoint's out-going e-mail with Exchange 2007

When using SharePoint 2007 with Exchange 2007, I found out that SharePoint just couldn't send out *ANY* e-mails. This could be e-mail notifications from Workflow actions, or simply the "Welcome" e-mail from the "Add User" administration in the site collection. From Site Actions -> Site Settings -> People and Group, select New -> Add Users,

If you don't see the "Send welcome e-mail to the new users" part, then the "Out-going email settings" has not been configured in the Central Administration. (To do so, go to Central Administration's Operations page, Topology and Services, Out-going email settings).

Now, if our out-going email settings is pointing to Exchange 2007 Beta2, upon clicking on "OK" SharePoint will complain that the e-mail message couldn't be sent out.

To check what's going on, we will need to inspect the SharePoint log files, at <program files>\Common Files\Microsoft Shared\web server extensions\12\LOGS. The actual error message is: "#160005: Bad response from SMTP host'master.iventsys.com.my': 530 5.7.1 Client was not authenticated ."

Ah.. "Client was not authenticated". Exchange 2007, by it's hardened default state, will not allow anonymous clients to send e-mails.

First off, we will need to create a Receive Connector in Exchange 2007 to receive e-mail from Internet. From the Exchange Management Console, select Server Configuration -> Hub Transport, New Receive Connector.

Now, if we try to send SharePoint's Welcome E-mail again from the New User page, we will still get the same error on the web page. However, the SharePoint log file turns out a different message:

#160005: Bad response from SMTP host'master.iventsys.com.my': 550 5.7.1 Client does not have permissions to send as this sender .

"Client does not have permissions to send as this sender." This is because SharePoint will use the user email in the "From Address" field of our Out-going Email Settings from the Central Administration's Operations page.

So, how can we enable Exchange 2007 to accept SharePoint's anonymous sender, masquerading as the administrator@iventys.com.my as above?

After searching throughout for this setting in Exchange 2007's Management Console, turns out that it never existed in the console. To do this, we have to use the management shell for Exchange. Referring to this article on Exchange 2007 Wiki: http://www.exchangeninjas.com/TUPMAppA; we need to do the following from the Exchange Management Shell:

add-adpermission '<receivername>' -User 'NT AUTHORITY\ANONYMOUS LOGON' -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

where <receivername> is the name of our Receive Connector of Internet type created above.

And that's it! Now my SharePoint 2007 and Exchange 2007 can live together happily ever after (well, until the RTM at least).

SharePoint's Contact Selector

(Ported from fooshen.blogspot.com) 

After first installing Sharepoint 2007 Beta2 (way back in May), the very first thing I noticed (besides all the bells and whistles), is the superior user interface; souped up with ajax at every turn. There is hardly any dropdownlist box, replaced with a rather sweet DHTML drop down menu that loads asynchronously.

Now, the one thing that caught my eye is the Contact Selector control (part of Sharepoint's WebControl library). This is used in many security settings page, for example in the site collection adminitration page as shown here.

What these controls do is quite similar to those outlook email fields, where we can type in an alias, and click on the "Check Names" image button to resolve the actual user name. Once resolved, the name will be underlined, or if unresolved, you will see the red wavy underline, similar to a typical spell-check error in a word processor.

Now, How to achieve this effect?

Conventionally, we can apply a 'text-decoration: underline' to a text input control (IE-only), to achieve an effect close to the first text-box (the "resolved" name). However, what about the wavy underline? It is not supported by any standard CSS implementations. The trick is to use a small image with a red underline, and set background-repeat attribute to repeat-x in the stylesheet.

In Sharepoint 2007, the CSS class used is ms-entity-resolved and ms-entity-unresolved respectively. Now, if we apply these attributes to a normal text-input, we get another problem. If we apply the above styles into a conventional <input type="text"> element, all we got is a textbox that applies the underline/wavy-underline in the entire input. Not good, as in Sharepoint 2007, we get to see this:

Furthermore, if we use the left/right arrow, the cursor will actually skip past the resolved/unresolved name, treating the entity as if one single character.
 

How to achieve this effect - the secret is here!
So, how the heck.. ? Well, to achieve this level of neatness, Sharepoint 2007 employes various DHTML tricks.. and most are specific to IE only. To achieve the above behaviour, Sharepoint didn't use any textbox input elements as we were made to believe. Yes, what we see here are not <input type="textbox"> tags; rather these are done using nested div and span, with the IE-specific attribute "contenteditable" set to "true".

To try this, use the following snippet:

<style>
.squiggle
{
   background-image:url("squiggle.gif");
   background-repeat:repeat-x;
   background-position:left bottom;
   padding-bottom:2px;
   vertical-align:text-top;
   font-style:italic;
}
.container
{
   border:1px solid #a5a5a5;
   overflow-x: hidden;
   width: 100%;
   color: windowtext;
   height: 18px;
   background-color: window
}
</style>
<div class="container" contenteditable="true" tabindex="0">
<span class="squiggle" contenteditable="false" tabindex="-1">
<div style="DISPLAY: none" displaytext="here"></div>
<span contenteditable="true" tabindex="-1">unresolved!</span>
</span>
</div>


By the way, the squiggle.gif image can be found in Sharepoint's Template\Images folder.

This is the magnified version of it (200x):

Cool tricks to use, especially if we are creating controls with spell checks capabilities!
However, when rendered in non-IE browser, SharePoint will simply render a normal TextArea element.

Vista and the BCD Editor

Okies, just installed Windows Vista RC1, after days of resisting the urge. I've finally managed to move all my data from my second partition and installed Vista as part of my dual-boot laptop. Now...dual-booting with Windows 2003 Server on one side, and Vista on another is neat, but Vista doesn't think so... On my boot up screen, Vista gives me two options: "Earlier Version of Windows", or "Vista". That's like asking me: "Use an antiquated OS or me?" Substitute the word "Earlier" with "Older" and you get the idea. Anyway, I thought that would not be a problem. Open up Boot.ini in notepad and change the description to my heart's content will do.

But wait.. there's no boot.ini for Vista!

In comes the new Boot Configuration Data Editor, or the BCDEdit command line tool.

For a start, I investigated what my boot options look like with the /v argument:

So how do we go about changing the description field of the Win2k3 partition? BCDEdit /? gives us a list of available commands (too long to list here). BCDEdit /set is what I'm looking for, and the format goes like this: BCDEdit /set {id} {datatype} {value}, where {id} will be the identifier value listed in our /v above. The {datatype} that we want to set is "description". To list the available datatypes, we can type "BCDEdit /? TYPES"

Thus:

So, there goes my BOOT.INI :)

.ctor

The obligatory Hello World blog post!

After finding out that I could actually host my technical blog at blogs.msdn.com, finally I'm moving over my blogspot entries. Well, I sure won't get my Google Adsense...but what the hell, it's like $0.50 over three months..

Welcome to my technical blog (yeap, I have another non-technical blog @ MSN Space).

Day job: Technical Solution Professional - Office Platform, Microsoft Malaysia.

Alter-ego: EPL junkie, .Net coder (code for anything that interests me at any particular time), and re-tiring Warcraft player.

Whatchablogginabout: Sharepoint and Office technologies, .Net in general.