Connex' Copper Coins

When I read the news the last days about the SharePoint Solution Generator included in the Visual Studio 2005 Extensions for WSS, I was immediately thinking "Those who come late, will be punished". So the SolutionCreator Project I intended to kickoff is dead now. It makes absolutely no sense to develop something, MS has already.

But checking out the VSE there are some drawbacks.
First the installation. Hey Microsoft, did you ever hear about people not installing stuff to the C:-Drive? Well, if, you ignored it with the VSE-Installer. The VSE installs the templates hardcoded to C:. What a Bummer. Took me quite a while to find out. Why not checking the registry for the location of the custom templates directory?
Second, the SharePoint Solution Creator has exactly the same problems I'm facing with the FeatureCreator-Project and my now dead SolutionCreator. Namely: Lookup-Fields. Those fields are commonly used all over our projects, and what a pity I can not transport them in features or solutions :( But hey wait, there is a solution for this. What is it, you might ask. I'll not reveal it right now, but version 1.1 of the FeatureCreator will support transporting of lookup-fields.

Which brings me directly to the next point. FeatureCreator. Many of you are waiting eagerly for the first release, and hey yes I know I'm far beyond my timeline. So the main question for me right now is, shall I release a Version now or shall I wait till RTM, which I hope to hold in my hands before 11/30. So mainly it's up to you folks. Want to have your hands on it now? Then leave a comment.

Also, yesterday evening (morning for you), I attended a pretty good LiveMeeting about the BETA2TR->RTM upgrade procedure. I hope the upgrade will be as easy as they said :)

With Office Launch coming closer, things start sorting out. So, if you are around Stuttgart Area, come to see me on the stage on November 21st presenting all the cool SharePoint-Stuff. I'll spend a beer afterwards ;)

Stay tuned for more news...

BETA2 TR has a known problem with starting workflows if you use a non-english environment (e.g. german).
The problem is that a conversion of a datime-field fails.

Since Microsoft has not posted a workaround for this yet, here is how to make workflows running:
If you change the default-language for the users to "english" all works fine:

1. Login to the Server, and start a cmd-Window.
2. enter "osql -E"
3. enter "use master" followed by return
4. enter "go" followed by return
5. repeat step 6 for all logins that access the server
6. ALTER LOGIN [MOSSBETA\SQLServer2005MSSQLUser$MOSSBETA$OFFICESERVERS] WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
   GO
7. restart the sql-server

For my german MSDE it looked like this:

ALTER LOGIN [MOSSBETA\SQLServer2005MSSQLUser$MOSSBETA$OFFICESERVERS] WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english];
ALTER LOGIN [NT-AUTORITÄT\LOKALER DIENST] WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english];
ALTER LOGIN [NT-AUTORITÄT\NETZWERKDIENST] WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english];
ALTER LOGIN [NT-AUTORITÄT\SYSTEM] WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english];
ALTER LOGIN [VORDEFINIERT\Administratoren] WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english];
ALTER LOGIN [VORDEFINIERT\Benutzer] WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english];
GO

 Like always, if you liked this, kick it.

Lately a lot of people asked me, how they can solve the problem with the failed Beta2TR-Installation using slipstream in standalone mode on a VirtualPC/VMWare.
Most went to a separate SQl Installation then, because nothing helped.
But here's how I got it working:

1. Start the installation in standalone mode as normal.
2. When the error pops up because SqlExpress installation failed; Send the Error-Report :-D, close the Error Box
3. Uninstall IE enhanced Security
4. Disable Popup-Blocker
5. Navigate to %CommonFiles%\Microsoft Shared\SERVER12\Server Setup Controller
6. Run SqlExpressWrapper.exe by doubleclicking on it.
7. Lean back, have a coffee or two
8. When the cmd-window disappears, start the Configuration-Wizard.
9. Voilá, send a smile to connex ;)

 Update:
I got some messages that SqlExpressWrapper exits at once.
If this happens start "SqlExpr.Exe". Follow the Install UI.

At the screen where you enter the name is a checkbox "Hide advanced configuration" make sure to uncheck it.

Pic1: Uncheck this checkbox!

At a later screen then you will be able to name the instance:
 
Pic2: Name the instance "OfficeServers"

There you go, leave the rest default and after finishing you can start the MOSS Configuration Wizard.

When deploying a Feature, sometimes it's necessary to access some files during activation. in Multi-Lingual Environments, this can become a real mess, to find out where the "FEATURES"-Directory actually is (Environment etc etc). But hey, good old MS gave us an easy way to get it:

 (excerpt from my Utilities-Class)

public static string FeaturesRoot
{
  get { return SPUtility.GetGenericSetupPath("Template" + Path.DirectorySeparatorChar + "Features"); }
}

Warcarft Fan or Southpark fan?

a MUST SEE! I laughed my ** off.

SP 1008 - Make Love, not Warcraft - South, Park, World, Warcraft - Dailymotion Share Your Videos

Today someone asked me how to solve the following problem. How to create a feature that contains DataViewWebParts? Well, of course off hand, this is not very complicated, but now the interesting point. How to make this DVWPs to lookup the list where to grab the data at runtime and not to use the list guid you provided at designtime? I bet you guess, the problem popping up here. After installing the feature (and the corresponding lists) the guids are different. What a bummer.
Now you could go ahead using a FeatureReceiver and alter the dvwps. Ugly Ugly Ugly.
There must be another way, and of course there is:

Just alter the dvwps-datasource at designtime! Make it use the list by name and not by guid:

<DataSources>
<SharePoint:SPDataSource runat="server" DataSourceMode="List" UseInternalName="true" selectcommand="&lt;View&gt;&lt;/View&gt;" id="dataformwebpart2">
<SelectParameters><WebPartPages:DataFormParameter Name="ListName" ParameterKey="ListName" PropertyName="ParameterValues" DefaultValue="MyList"/></SelectParameters>
[...]
</SharePoint:SPDataSource></DataSources>

Just replace ListID by ListName and the DefaultValue (guid) by the name of the list, eh voilá!
You might want alter some more locations of course, but hey I'm just giving hints, not a cook book ;=)

 Like always, if you liked this then kick it :)

Just a short note to those who update an existing Beta 2-Installation to the Technical Refresh:

If you run the Upgrade-Wizard, make sure the account that is used to run the Timer Services is a Farm Administrator.
Else the wizard will run forever sleeping, because the upgrade fails, but it does not recognize!

So what to do if you already applied the patches, but the account is not a farm admin?
Basically you have two options:

1. Add the account to the local group "WSS_RESTRICTED_WPG"
   or
2. Change the service-user to a user that is member of that group

Back from vacation in Italy with lousy UMTS-Connection :( but very nice weather :)

As you might have noticed I'm a bit *cough* behind my schedules. No excuses for this. You will have heard them all ... Vacation, Beta/TR-stress,too much online poker.... But well mainly I'm behind, because of my efforts to look for a new job. So, if you are looking for a SharePoint pro you might be interested to hire me *wink*

About the projects I kicked off:

• SPEAK (SharePoint External Accounts administration Kit)
  Planning is done, first implementations are done. Watch out on CodePlex for the first version. Overallstatus ~60% to alpha
• FeatureCreator
  Planning is done, First version is running (Beta 2), updates/checks for TR in progress. Overallstatus ~90% to beta1.
• SolutionCreator
  Planning is done, First lines of codes are written. Overallstatus ~30% to beta1
• TimerConfigurator (to be announced)
  Planning is done, Overallstatus 10%

Also starting with my next MOSS-blogentry I will run a hybrid blog, and start blogging in German as well. Mainly because there are not so many German SharePoint bloggers. The German blog will get it's own blogspace.

stay tuned.

nota bene: This post should have the category "other" but neither Live-Writer nor Live-Spaces give me an opportunity to add a new category and I'm too lazy to start word now ;)