Thursday, January 18, 2007

MOSS Danger! Don't modify the fieldtype without making a backup!

Well what happened to me was the following, I had an Issuelist (migrated from a Wssv2) and was playing with the new opties that are available for a Multiline text fieldtype. I enabled the "Append Changes to Existing Text " function on a required field column. By doing this the values remained but everytime I edited an issue, while the field was filled in, the form requested that I need to fill in the field. This is not very desirable for a field that is only required to be filled in at creation time. So I disabled the 'Append Changes to Existing Text' and was then suprised to find out that for all the existing items the field values were deleted!!! Lesson learned : never (!) change the type of a (even it is an adjustment of the current type) field without making a backup or test it thoroughly!

Thursday, January 11, 2007

MOSS 2007: Installation error :\

UPDATE:

Fixed! Problem was that the WMI service did not function properly. Apparently during the creation of the configuration - and admin database, Sharepoint wants to get some information through the WMI interface. The cause that the WMI service did not function properly lies in the fact that the Windows Firewall and ICS service were running. Once I turned the service off and restarted the WMI service, the WMI service worked. The reason why i figured it had something to do was the cause of the error: System.Management.ManagementException: Initialization failure -----------------------------------------------------------------

We have an environment which consists of : - Windows 2003 Server + IIS with a SPS 2003 environment (Front-end server) - Windows 2003 Server + SQL Server 2000 with sp4 installed (Back-end server) With two service accounts that both have local administrator rights + the necessary database rights. Now everything works fine for the SPS 2003 environment but when I want to upgrade to MOSS2007 using the gradual upgrade method (I've not tried to the inplace upgrade but I did try the "new install" method and it gave the same error) i get the following error when I ran the Sharepoint Configuration Wizard (step 2)

01/10/2007 10:56:16 10 ERR Task configdb has failed with an unknown exception 01/10/2007 10:56:16 10 ERR Exception: System.Management.ManagementException: Initialization failure at System.Management.ManagementScope.Initialize() at System.Management.ManagementObject.Initialize(Boolean getObject) at System.Management.ManagementClass.GetInstances(EnumerationOptions options) at System.Management.ManagementClass.GetInstances() at Microsoft.SharePoint.Administration.SPAdministrationServiceUtilities.GetWindowsDirectory() at Microsoft.SharePoint.Administration.SPAdministrationServiceUtilities.GetWindowsTempDirectory() at Microsoft.SharePoint.Administration.SPServer.GetWindowsTempDirectory() at Microsoft.SharePoint.Administration.SPServer.StaticProvision(SPConfigurationDatabase configurationDatabase) at Microsoft.SharePoint.Administration.SPFarm.Join() at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.CreateOrConnectConfigDb() at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.Run() at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask() When I look on the database server, I see that the two databases are created (Sharepoint_Config & Sharepoint_Admin_Content).

Things I've tried to resolve it: 1. Created the databases before running the Configuration Wizard using SQL Enterprise Manager 2. Attempted to use the precreated databases using the PSConfig cmdline tool I think it has something to do with not having set the proper rights to the service accounts. And for the simplicity I've only used one account which is : - local administrator on each machine - got every 'server role' as a database user on the database server What suprises me btw was that the machine account of the front-end server was added as a user in the database. And another thing wat suprises me is that the databases are in fact created, thus the account has proper rights but it failed to do something I cannot get my grips on :(

So please help! :)

Wednesday, November 29, 2006

Certifications announced!

I always thought it was a bit odd that Microsoft did not have a certification programme for just WSS and/or SPS but only combined with CMS, which in my opinion is too broad. Many of my collagues are experienced in Sharepoint or CMS and very very few (actually none) in both. Well for people like me, there is good news! Check out this post from Trika

 

Developer certifications for Office 2007

For Office, there will be three MCTS level certifications for developers, each requiring 1 exam. MCTS is Microsoft Certified Technology Specialist, which is the technology-series certification in the new format of certification. There is also a Microsoft Certified Professional Developer (MCPD) series that focused on job roles... but we won't have any MCPD for office. I think the betas for these three are scheduled for January (more on betas).

MCTS: Office SharePoint Services (MOSS): Application Development (70-542)

MCTS: Windows SharePoint Services: Application Development (70-541)

MCTS: Office 2007 Client: Application Development (70-543)

More on the new certifcation format here: official overview: http://www.microsoft.com/learning/mcp/newgen/default.mspx or here: from one of my friends/co-workers at MSL for interesting take: http://vishaljoshi.blogspot.com/2005/12/are-next-gen-certs-launched-to-make.html

Thursday, November 23, 2006

The configuration database could not be updated

Well I got an error when I tried to add a webpart using STSADM, the thing that suprised me that I managed to do it a couple of hours earlier. Only difference was that I was publishing the webpart on a 'updated' virtual server (hostname was changed). Luckily using Google'as my best friend, I found the solution ;)

Amazing how many things can go wrong. As a mental note-to-self: If I ever end up again with weird errors like 'The configuration database could not be updated.' then the problem is likely due to a change in the site configuration: SSL added, domain name change, IP change, etc. To fix: check web parts: C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN>stsadm -o enumwppacks this will show to what sites the web parts are linked to reinstate the site configuration in IIS remove the packs stsadm -o deletewppack -name make the changes to the site configuration reïnstall the packs Likely theirs an easier fix, but can't be bothered to find out.
Thanks Rexy!

Thursday, November 09, 2006

Document library with content approval default in site definition?

The customer I'm working for now required that for a particular area template, that the document library has content approval on by default. I thought that wasn't really a tough requirement (and it ain't if you know where to look for and know the (undocumented) syntax) ;) So here is a step-by-step guide to get a document library that is created during the creation of a site with content approval (and versioning) on by default:

1. Open the SCHEMA.XML file in the folder 60\TEMPLATE\1033\