peoplenet's blog

The best session so far at SPC 08 was Todd Bleeker's inspirational talk on the daunting task of migrating SharePoint Designer workflows to Visual Studio.

Often customers want to take a specific SPD workflow and use it on different lists – but as most of you know, this is not possible because an SPD workflow is tied to one list, and one list only. If you need to attach a workflow to several lists in a site collection, you are forced to build the workflow from scratch in Visual Studio.

Until now. Todd Bleeker went through the process of migrating a simple SPD workflow to Visual Studio. And it's difficult! And time-consuming.

Basically, you need to go through a long process of importing files, renaming variables, attaching new dll's, changing XML and loads more. It's not for the faint of heart and at the moment you're not likely to be using this method for other than proof-of-concept projects.

However, Todd is working with Paul Schaeflein and Mindsharp to automate the tedious migration process and he indicated that their efforts may result in a turn-key product sometime in the future.

The one great use of the migration method is prototyping, i.e. you can let your users develop a workflow in SharePoint Designer with most of the functionality added. All the kinks can be ironed out in this phase and once the user is happy with the workflow, the developer can take over and migrate the workflow to Visual Studio. The advantage of this approach is that you free up developer resources and eliminate much of the development time where the developer and user need to communicate about tweaks, changes etc.

You can read more about the step-by-step migration process at Paul Schaefleins blog: http://mindsharpblogs.com/paul/archive/2008/03/03/4399.aspx. More details should follow soon.

Saturday evening I arrived along with 13 colleagues at the US coffee capital to take part in the '08 installment of the Microsoft SharePoint Conference. We are all excited to be here – and I plan to blog on some of the interesting developer-oriented tracks on offer here at the Washington State Trade and Convention Center.

I've just attended the two keynotes by Bill Gates and Kurt DelBene. By far the most interesting announcement was Microsoft Online Services which seems to be Microsoft's answer to Google Apps, only more targeted towards businesses rather that individuals. Also, Search Server Express, looks like a promising and – interestingly – free product.

Stay tuned for more posts from Seattle as and when I get the time to sit down with my laptop and a cup of Starbucks!

I'm the new kid on the blog: My main focus will be on the business potential of SharePoint 2007. Coming from background in strategy, e-business and knowledge management I'm really excited about the conceptual changes in 2007. Yes boys and girls, we are going to see some really interesting solutions coming from this platform. 

Though, this post is of a quite practical nature:

Recently, PeopleNet got a request from a customer who experiences problems with MOSS Workflow: he couldn't get the Workflow to include a valid URL to a list item in the email generated by the Workflow.

None of the fields in "Add Lookup to Body" seems to make sense. For instance, when using the field "Encoded absolute URL" the resulting URL looks something like this: http://intranet/Sites/DHL/Lists/Tilmelding/1_.000 . (Notice: this will work just fine in a document library).

You could solve this by using Visual Studio, but who wants to do that unless you have a gun to your head?

The solution seems to be to use HTML in the Workflow, thereby putting the available fields together:

Example:

This is a link to the <a href="http://intranet/[%LISTNAME ath%]/DispForm.aspx?ID=[%LISTNAME:ID%]"> list item</a>

As simple as that!

I hope this was helpful – please share your own experiences with Workflow

It has been a while since I was granted rights to add blog posts on PeopleNets SharePoint Blog, and was introduced by Sondergaard.

My main area of interest is customizing and branding the look and feel of SharePoint, and I have created themes and templates for SharePoint 2003. This was done directly on the server using Visual Studio by editing xml files, stylesheets and aspx pages, to customize the entire portal or sites. I never used FrontPage, because it had the issues with unghosting portalareas and teamsites. Moving on to editing masterpages and styles for MOSS I read different blogs on the Internet to see what the major change in customization was from 2003 to 2007. I watched the webcast from Microsoft and attended the European SharePoint conference in Berlin and learned a few tricks.

So now I am customizing using the SharePoint designer, first creating a masterpage, copying the core.css into a new stylesheet, and editing the new stylesheet to overwrite all the classes from core. As I was developing a masterpage to match a specific design, I added different web parts to the page, to see if I missed any classes and I came across a problem with the toolbars in some of the web parts.

In the design, hyperlinks was specified to be black, and they still had the #003399 blue color from the original stylesheet when the page was in editmode.

Having copied the core.css and made sure no classes with blue links wasn't overwritten, I took a look at the server and found out that some styles were still specified in the global stylesheets in the 12 "hive".

C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATELAYOUTS1030STYLES

Accessing the server, I copied the classes and pasted them into my new customized stylesheet, and the links were black.

We all know the steep hardware requirements for running a MOSS server and none of us have a desktop (let alone a laptop) that meets these specs. Microsoft has received a lot of criticism for not providing a properly integrated development environment for MOSS 2007 which makes it feasible to develop on anything but an actual server.

Not willing to run 2003 Server as my main OS I set about experimenting with Virtual PC 2007 on my Vista Enterprise-equipped laptop.

Charlotte had already created a virtual machine with 2003 Server and MOSS 2007 so I ran all the updates and was ready to test my new MOSS server. Things ran pretty smoothly, especially if I didn't access MOSS through the Virtual PC interface, but rather through a browser on the host machine.

Then I went all the way and installed Visual Studio 2005. Not really expecting great results, I fired VS up for the first time – and no, it wasn't a great user experience.

Remote Desktop to the rescue
My laptop is equipped with 2 gigs of RAM which is fairly commonplace these days and I assigned only 1 gig to the virtual machine. This sounds ridiculous but the server ran at an acceptable speed unless I accessed it through the Virtual PC interface.

Using Visual Studio within Virtual PC was almost painfully slow. Instead I connected to the server with Remote Desktop in full screen mode, and this was much faster. In fact, working with Visual Studio this way was a rather pleasant experience – not lightning fast, but acceptable.

I've only developed a couple of test web parts and deployed them straight to MOSS but it all worked flawlessly. I'm yet to try this with bigger projects but so far I haven't encountered any problems.

Portability
The great thing about setting this up in Virtual PC is how portable it makes the environment. Once I had completed the installation and run the updates I took a copy of the .vhd file (the virtual hard drive, about 8 gigs) and kept it in a safe place for future installations.

In theory I could create the perfect development environment with MOSS and all the tools and documentation installed – then save the .vhd file and use it as a template for all developers in my organisation.

This would make it extremely easy to distribute the development environment to different users with different hardware. Also, transferring an existing development environment from an old to a new PC is a breeze with this setup.

I'd be very interested in hearing about your experiences with this kind of setup and how it fares with large Visual Studio projects. In any case, I'll report back when I've put the system through its paces, so stay tuned.

Please extend a warm welcome to the newest member of our blog team at Peoplenet, Charlotte Green!

As far as I know, she may be the first female blogger on Sharepointblogs.com but feel free to prove me wrong.

Charlotte will be focusing on SharePoint installation issues as well as branding and customisation of SharePoint.

You can programmatically add a Content Editor Web Part (CEWP) to a a SharePoint 2003 WSS page.

Let's assume that you've already opened a WSS site by using the openWeb() method. Add the following code:

ContentEditorWebPart MyCEWP = new ContentEditorWebPart();
MyCEWP.ZoneID = "Left"
MyCEWP.Title="Web part title"
MyCEWP.FrameType= FrameType.TitleBarOnly;
MyCEWP.PartOrder = 2;
XmlDocument xmlDocxmlDocMyCEWP = new XmlDocument();
XmlElement xmlElementDetails = xmlDocxmlDocMyCEWP.CreateElement("NewCEWP");
xmlElementDetails.InnerText = "<p><b>My new web part</b><br />Lots of text here…</p>"
MyCEWP.Content = xmlElementDetails;

Having created the above web part you must also add it to the page:

SPWebPartCollection webPartCollection = TheWSSweb.GetWebPartCollection("default.aspx", Storage.Shared);
webPartCollection.Add(MyCEWP);
ThisWSSweb.Update();

You need to reference Microsoft.SharePoint.WebPartPages and System.Xml in order to make the above example work.

Today at the SharePoint Conference in Berlin, Ben Robb of cScape Ltd gave a talk about configuring internet-facing web sites running MOSS 2007/WCM.

He brought up some interesting points about securing the application against unauthorised content editing and attacks from hackers.

Make sure your installation check list contains a least the following items:

1. Enable firewalls and standard network security
Fairly standard stuff, but necessary all the same.

2. Disable SMTP and incoming mail
In essence, you shouldn't be running services on the server that aren't necessary for MOSS. Also, close any ports that MOSS doesn't need.

3. Secure the Central Administration site
Surprisingly, it is very common to leave this entry point wide open. The admin site should be accessible only via an SSL connection .

4. Use lockdown mode
Use this stsadm command to activate lockdown mode:
stsadm -o activatefeature -url <url> -filename ViewFormPagesLockdownfeature.xml

5. Restricted reader role
The anonymous user should have a restricted reader role which only enables viewing of pages, documents and images.

6. Policies
Constrain the maximum access per web application and deny all write access via http://sitename:80.

7. Content deployment
Use different servers for authoring and the actual internet-facing web application. Content generated on the authoring server (typically within the intranet) should be pushed out to the public site using scheduled content deployment jobs.

…

To many administrators the above bullets merely point out the obvious and do feel free to leave comments if you have any additions to the list.

Thanks to Ben Robb for providing 99% of the info for this post.

At the SharePoint Conference in Berlin, Patrick Tisseghem gave a talk about the MOSS 2007 object model and the one thing that caught my eye was the new options available for doing impersonation.

Working with impersonation can be a pain and sometimes you feel like you're cheating if you have to resort to impersonation. If you've ever worked with impersonation in SPS 2003, I'm sure you know what I mean!

In MOSS 2007 you can use user tokens instead of doing old-fashioned impersonation. This opens up a number of possibilities which I will discuss in detail in a future post .

Along the same lines, MOSS 2007 allows you to easily check if a user has permission to carry out a certain task (or a series of tasks) without having to resort to trickery with try/catch blocks etc. Using the DoesUserHavePermission method on the site with the users login name returns true if the user has sufficient privileges to execute the code. Here's an example:

If(site.DoesUserHavePermission(SPContext.Current,Web.CurrentUser.Loginname, SPBsePermissions)
{
       // Do stuff here
}

Please forgive me if the above code isn't spot on, as I've yet to try it out myself. Still, it looks extremely usable and I will certainly be exploring this subject more in the weeks to come.

Lastly, I'll mention a new way of executing code with admin privileges. A simple SPSecurity.RunWithElevatedPriviliges() let's you briefly delegate admin rights to a user. This saves you doing normal impersonation of an administrator and it definitely makes your code more generic and manageable.

I've just arrived at the SharePoint conference in beautiful Berlin. The sold-out event starts tomorrow and the programme for the next few days is very exciting.

Naturally, I'll be focusing on the developer tracks and hopefully I'll have time to convey some of the action to you out there. Stay tuned for more info.

I'd be interested in knowing if any fellow bloggers (or indeed, readers) will be attending the conference. Maybe we can meet up for a chat!