It has taken a good year to go from the initial idea to the full blown company launch, complete with a rich e-commerce website, full time employees, multiple products under development and a beta version of the first product available for download. But here we are and we are pretty pleased with what our hard work, dedication and countless sleepless nights have achieved.

Our first product, a PDF Converter for SharePoint, will be released as a downloadable beta version in the next day or so. We will announce the availability on our Blog as well as our Twitter stream, so make sure you subscribe to our feeds.

If you are interested in SharePoint news, announcements and articles then please subscribe to the new company blog as we will move all the SharePoint related content from the old (this) blog to the new one.

More information can be found on www.muhimbi.com.

Please note that all new SharePoint related content is now hosted on the blog at www.muhimbi.com.

As most SharePoint developers are aware, explaining to customers how to deploy SharePoint solution files using the command line can be a challenging exercise.

Fortunately, some clever developers have created a GUI wrapper to make the entire process a bit more user friendly.

Unfortunately this cool application does not allow Web Application or Web scoped features to be deployed as that results in the ‘Feature xxxxx is WebApplication-scoped, and can not be added to the Site.’ error message.

There is a workaround, which is to delete the ‘FeatureID’ and ‘FarmFeatureID’ lines from the setup.exe.config files. The only drawback is that the administrator will need to manually activate the feature on the target Web Application.

With thanks to Roel Hans Bethlehem for this useful trick.

Please note that all new SharePoint related content is now hosted on the blog at www.muhimbi.com.

Please note that all new SharePoint related content is now hosted on the blog at www.muhimbi.com.

As we are providing our SharePoint solutions in multiple languages, we need to make sure that each and every translation is properly tested.

As it is not feasible, even with virtualisation, to have an instance of Central Administration for every available language, we need to be able to quickly switch the language used by Central Administration to test any of our custom translations (Feature descriptions, custom admin pages, etc.)

There is no official ‘Microsoft way’ to switch the CA language, but if you are running in a test environment then you may want to consider the following trick. Although we have not experienced any problems we don’t recommend switching CA languages in a production environment as any manual changes to your SharePoint databases will void any support contracts you may have with Microsoft.

Ok, enough talk, here is how to switch the language:

1. Look up the Locale ID for the language in this table. E.g. Japanese = 1041.
2. Use your favourite SQL Editor (e.g. SQL Server Management Studio) to open the ‘Webs’ table in the Content Database used by Central Administration.
3. You will most likely find only a single row in this table. If not then you will need to navigate to the correct row.
4. Update the ‘Language’ field to the correct locale, in our case 1041.

That is it. There is no need to do any ‘IISRESETs’, just refresh whatever CA page you are on and it will automatically switch languages.

A full list of languages for which Microsoft provides support in SharePoint can be found here.

Please note that all new SharePoint related content is now hosted on the blog at www.muhimbi.com.

Please note that this posting has been moved to the blog at www.muhimbi.com.

At the risk of sounding backwards, and being pointed out that this functionality has existed for years, I would like to share this little Remote Desktop gem that I found out about today.

In the latest Remote Desktop client (I am on Windows 7) it appears that you can copy files from your local machine to your remote desktop session (and vice versa) using the clipboard. There is no need to browse through ‘shared tsclient’ drives, just copy the source file, browse to the destination folder in your remote desktop session and paste.

It even works when pasting files directly into your application, such as Outlook emails.

Remote Desktop drive sharing doesn’t even need to be enabled.

This is such a time saver.

As I like living on the cutting edge I promised myself that I would convert my main laptop to Windows 7 the moment the official Beta version is released. Although this moment is still a few weeks away for most people, I have managed to get my hands on a shiny copy of the official Beta (Build 7000).

So after a quick backup, full wipe of my Vista laptop and an approximately 20 minute wait for the Windows 7 installer to finish, the system booted without error.

Shiny

This is not a comprehensive review, but my impressions in bullet style and no particular order are as follows:

1. It is stable. Haven’t had a single crash, not even after installing all my apps and doing a day’s work on it.
2. It is fast. Again difficult to compare as my previous Vista install was nearly 3 years old, but it feels snappy.
3. The new window manager is fab. ‘Docking’ windows left and right works great. Quick tip: when using multiple monitors it works slightly differently, use the Windows key in combination with the left and right cursor key to dock windows.
4. You can minimise all applications except for the current window by ‘shaking’ it.
5. The new task bar is very functional, but it looks messy. I can’t put my finger on it, but the different visual styles for applications, running application, applications with multiple windows and applications with a progress indicator just doesn’t feel right.
   
   
   
   
6. I really don’t get the importance of Aero peek. So what if I can glance on my desktop, why would I want to do that?
7. It appears that my battery lasts quite a bit longer. I have no exact figure but I estimate it lasts about 15% longer.
8. Probably related to the previous point, but the fan of the laptop doesn’t come on nearly as often as under Vista.
9. Multi monitor support has improved somewhat, you can now specify the monitor that gets the start menu. Unfortunately a separate task bar (like Ultramon provides) is still lacking.
10. Before installing my main concern was IE8. I don’t know what the fuss is about, but it works just fine.
11. The current version of Live Mesh disables Aero, which is very annoying. A patch (to Live Mesh) is promised for the beginning of the new year.
12. The retarded Flip 3D is still present. Fortunately the excellent Expose clone that is Switcher works just fine.
13. Manually running the Performance Index Calculator left my screen resolution quite low and I couldn’t set it back. A reboot fixed it.

Windows Media Center, which I love, has had a significant update as well.

1. Fewer menus to navigate / ignore (good).
2. Overall look and feel has been improved.
3. Not sure if this is new, but it is now possible to connect to a ‘Recorded TV’ folder on a different system. Unfortunately playing a TV Show that was recorded on my main Vista Media Center system crashed Media Center on Windows 7.
4. All frikkin’ Codecs are finally included with Windows. Well, at least Divx is as my ripped DVDs play fine without the need for any 3rd party installers.
5. It is beyond me why they still provide different menus for ‘Movie Library’ and ‘Video Library’. Try explaining that difference to my mum.

All in all very good. I will continue to use it until they release the final version this summer.

Updates:

1. Tim Sneath has posted a lot of Windows 7 secrets. Very useful.
2. Problems reporting feedback on Windows 7? Use this link to add Windows 7 to your Microsoft Connect account.
3. Some Windows 7 specific drivers for Microsoft products such as their keyboard, mouse and webcam range of products.
4. Completely forgot that you have to install the Windows Mobile Device Center to sync and use your Windows Mobile phone as a modem.

Wow, sometimes when trying something while not expecting it to work, it actually does work.

I made a screenshot of a bug and was already dreading the ‘paste in MS-Paint / Save / Add / Browse for file’ dance when I tried pressing ‘CTRL-V’ in the TFS 2008 File attachments tab.

Guess what… it worked! A file was created and automatically attached. Brilliant.

Update: It also works with other clipboard formats. Try copying content of an MS-Word file and pasting it.

Please note that all new SharePoint related content is now hosted on the blog at www.muhimbi.com.

Recently I was looking into what the best way is to store settings centrally in SharePoint. Not just for a single Site Collection, but rather at the Farm and Web application level.

Sure, we could mess about in the web.config, which gets messy if the settings can be modified from a SharePoint screen, or use the ‘Settings’ property bag, which is available on Farm, Site as well some other objects, but this doesn’t provide much granular control in more complex scenarios.

So, enter the Hierarchical Object Store (HOS). The HOS allows settings or other kind of data to be stored for nearly every existing SharePoint object that inherits from SPPersistedObject, which is pretty much everything. As this article is not about programming the HOS, check out this very simple example by Maurice Prather.

Microsoft’s guidance and documentation on this subject is pretty thin, so I managed to corrupt the HOS within hours which had all kinds of nasty side effects such as not being able to call SPFarm.Update any more.

Great, so I have managed to muck up my SharePoint installation and get all kind of very generic error messages such as ‘Security Exception’ and the somewhat more descriptive

“The platform does not know how to deserialize an object of type Muhimbi.Licensing.SharePoint.LicenseStore. The platform can deserialize primitive types such as strings, integers, and GUIDs; other SPPersistedObjects or SPAutoserializingObjects; or collections of any of the above. Consider redesigning your objects to store values in one of these supported formats, or contact your software vendor for support.   at Microsoft.SharePoint.Administration.SPAutoSerializingObject.
DeserializeBasicObject(XmlElement xmlValue)”

What I could have done to resolve this is to restore the previous day’s backup (your are making backups right!) of the configuration database, but what would be the fun in that? I would learn very little about what is going on under the hood.

After investigating the schema of the Config Database it became clear that HOS information is stored in 2 tables named ‘Classes’ and ‘Objects’. Similarly to C#, records in the Class table define some meta information about the makeup of a Class and the Objects table contains instance data for the class, basically the Object.

By Querying these tables for the type specified in the error message above I was able to find and delete existing instances of the corrupted data.

SELECT Id, BaseClassId, FullName FROM Classes where FullName like 'Muhimbi%'

SELECT Id, ClassId, ParentId, Name, Status, Version, Properties FROM Objects WHERE Name LIKE 'Muhimbi%'

Note that the Object table may also return some WSP files, don’t delete these. Always make sure that entries are removed from Objects before removing them from Classes as there is some referential integrity checking going on.

After cleaning up the existing entries in these tables the error messages I received after calling Update on any SPPersistedObject changed from SecurityException to the more descriptive Deserialization error listed above. Clearly something was still finding a reference to the offending type.

Some further investigation revealed that the Farm also has an entry in the Objects table. The Properties field for this entry stores a large blob of XML containing a reference to our dodgy HOS type. We stored our information using SPFarm as the parent, if you have used a different parent then just perform a ‘Like’ search for you type name in the Objects.properties field.

Selecting the Farm object works as follows:

SELECT * From Objects where ClassId = '674DA553-EA77-44A3-B9F8-3F70D786DE6A'

The Properties field contains the following XML blob. The relevant section has been highlighted in red.

<object type="Microsoft.SharePoint.Administration.SPFarm, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"> <sFld type="Int32" name="m_PersistedFileChunkSize">4194304</sFld> <fld name="m_PairConnectionString2" type="null" /> <fld type="Microsoft.SharePoint.Administration.Pairing, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" name="m_Pairing">None</fld> <sFld type="Boolean" name="m_SqmEnabled">True</sFld> <sFld type="Boolean" name="m_WatsonEnabled">True</sFld> <sFld type="Boolean" name="m_DownloadErrorReportingUpdates">True</sFld> <sFld type="Boolean" name="m_bUpgradeFinalized">True</sFld> <sFld type="Boolean" name="m_bCommandLineUpgradeRunning">False</sFld> <sFld type="Boolean" name="m_reghostOnUpgrade">False</sFld> <sFld type="Guid" name="m_clsidExternalBinaryStore">00000000-0000-0000-0000-000000000000</sFld> <fld type="System.Collections.Generic.Dictionary`2[[System.Guid, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.Version, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="m_Versions"> <sFld type="Guid">00000000-0000-0000-0000-000000000000</sFld> <sFld type="Version">12.0.0.6318</sFld> <sFld type="Guid">77e7f90e-1989-46c2-ad65-361a53dcb2e0</sFld> <sFld type="Version">3.0.4.0</sFld> <sFld type="Guid">6ac833ea-3f8d-46b6-8b30-92ac4553a742</sFld> <sFld type="Version">12.0.1.0</sFld> </fld> <fld name="m_UpgradeContext" type="null" /> <fld type="System.Collections.Hashtable, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="m_UpgradedPersistedFields" /> <fld type="System.Collections.Hashtable, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="m_Properties"> <sFld type="String">Muhimbi.Licensing.Configuration.LicenseStore</sFld> <fld type="Muhimbi.Licensing.SharePoint.LicenseStore, Muhimbi.Licensing.SharePoint, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c9db4759c9eaad12" /> </fld> <sFld type="String" name="m_LastUpdatedUser">MUHIMBI\jeroen.ritmeijer</sFld> <sFld type="String" name="m_LastUpdatedProcess">w3wp</sFld> <sFld type="String" name="m_LastUpdatedMachine">GBSAVDWS002</sFld> <sFld type="DateTime" name="m_LastUpdatedTime">2008-12-08T15:03:02</sFld> </object>

Basically what you are looking for is a ‘fld’ element with a name attribute of ‘m_Properties’. As my farm object only contained my own HOS data I replaced the section marked in red with:

<fld name="m_Properties" type="null" />

After a quick IISRESET, just to be sure, everything worked fine again.

Note that the entire HOS seems immature, brittle and not very well thought through. I recommend you only use it if you really need to. If at all possible use the Properties collection on any of the existing objects. In the end I ended up creating a very simple object that only stores one value in the HOS, this value contains an XML Serialised object hierarchy of what I really want to store.

Another day in my life gone that I will never see back.

Please note that all new SharePoint related content is now hosted on the blog at www.muhimbi.com.

As I mentioned before, oh the joy of working on the cutting edge!

This time I was installing Team Foundation Server 2008 (TFS) in combination with Report Server 2008, an officially supported scenario.

At first look everything appeared to have been installed correctly, however any application that tries to talk to the Reporting Server using the web services interface (Most notably the famous TFS Administration Tool) fails horrible due to what appears to be a bug in TFS 2008.

TFS internally stores a number of URLs for support services such as SQL, SharePoint and Report Server and exposes these URLs via it’s object model. However the URL it maintains for the Reporting Service points to the Deprecated SQL 2000 Reporting Service Web Services Interface.

Great, I really wanted the Administration Tool to work so I decided to dive straight in and see if I could fix it.

Follow the steps outlined below to make everything work properly:

1. Navigate to the TFS Tools directory. Note that mine is located on the E drive.

CD "E:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Tools"
 

2. Export TFS' current settings using the following command:

tfsreg /EXPORT TFSReg.xml <name of sql server>
 

3. Change the URL for the reportservice as follows:
    
   * notepad tfsreg.xml
   * search for ReportService.asmx
   * replace with ReportService2005.asmx
    
4. Update the changed settings to TFS

tfsreg /Overwrite TFSReg.xml <name of sql server>

For some reason these settings appear to be only loaded the first time someone connects to TFS and are subsequently cached. I can only hope TFS expires this cache at least once a day otherwise making changes such as this is going to be a nightmare in organisations with more than a handful of developers.

So, on the server as well as all clients, search and remove for all instances of ‘RegProxyFileCache.xml’ in the user profile directories. I used a search in "c:\users" (or "c:\documents and settings" if you are on XP or 2003) as the path contains an unfriendly GUID.

Now, if you think that this will make the TFS Administration Tool work then you are sadly mistaken. The ReportService.asmx (SQL 2000) is incompatible with ReportService2005.asmx so some changes need to be made to the source code of the TFS Administration Tool.

1. Download the code for version 1.3 (changeset 29980)Don't be tempted to download the latest code as it is a work in progress and some fields are hardcoded (Note to the author, hardcoding port numbers for SharePoint is not a good idea)
    
2. If you are developing on an X64 workstation then update all projects in the solution to use X86 (Project Properties / Build / Platform Target), otherwise the 32bit GAC entries for TFS cannot be found.
    
3. In the Microsoft.DDSolutions.SqlReportServer project open 'Web references' and change the "Web reference URL property of the ReportServer reference to http://<your reporting server>/ReportServer/reportservice2005.asmx. This URL is set at runtime, but manually setting it now updates the schema.
    
4. In ReportingServiceProxy.cs change line 22 to:

public ReportServer.ReportingService2005 SQLReportingServices = new Microsoft.DDSolutions.SqlReportServer.ReportServer.ReportingService2005();

5. And in the same file line 66 to:

ReportServer.Role[] rsRoles = SQLReportingServices.ListRoles(Microsoft.DDSolutions.SqlReportServer.ReportServer.SecurityScopeEnum.All);

That is it. Everything is working fine now and as an added bonus your Team Explorer can connect properly to the reports as well.

Please note that all new SharePoint related content is now hosted on the blog at www.muhimbi.com.

For some reason the ‘Site Actions’ menu does not display the ‘Edit Page’ menu for all pages in SharePoint. This is particularly baffling considering the editing functionality is available in the background.

Here is how you enable it:

1. Navigate to the page you want to add a web part to, e.g. a Content Editor Web part.
    
2. Remove everything on the URL after “?ID=#“
    
3. Append the following to the end:
   
       &PageView=Shared&ToolPaneView=2

That is it. Common pages you may want to edit this way are the DispForm.aspx and EditForm.aspx pages for the files in a document library or any other list.

A nice side effect is that once a page has been modified the ‘Edit Page’ menu becomes available in the ‘Site Actions’ menu.

Please note that all new SharePoint related content is now hosted on the blog at www.muhimbi.com.