• Operational Excellence (tips on setting up and deployment for best performances)
• Team Collaboration Sites
• Publishing Portals
• Search
• My Sites
• Developing Custom Applications
• Additional Resources

I have only started exploring the site but I feel like this is already a must-have favorite on my Internet browser!

Well, I know I have run this command numerous times already:

stsadm -o addwppack -filename <abc.cab> -globalinstall -force

But today, when I tried to run this command again, I got the message:

Object reference not set to an instance of an object

Webpart deployment failed.

The first thing I thought of is permission issue, I am running this command with an logged in account which is a member of the administrators group on both the WFE and SQL Servers but this account is not the same as the database access account I used when going thru configuration wizard. So I just go to Central Administration and added myself to have full control to the web application that I am interested at and also added myself to be part of the farm administrator group. (That should really do the trick - I thought to myself)

No luck. Same error message.

Added myself to be part of the security groups related to MOSS on WFE?

Still...... No luck.

Next, I went into SQL Server. I noticed that the logged in account I used don't have any access at all to the admin_content database, so I added the account as db_owner to admin_content.

YES! This works!

Really, new things learned in every brand new day

Yesterday, when I was doing a fresh MOSS installation on one of the VMs, I got the error when running SharePoint Configuration Wizard and it failed at the step of creating configuration database.

... and it immediately rings a bell in my head: I am not running the wizard as my usual logged in account. In fact, I am just running the wizard as someone who is part of the administrator group on the WFE server and the backend SQL Server.

Knowing that I can logged in to the SQL Server box but not able to see all the settings in SQL Server, I know exactly what is missing from my new logged in account:

• Security Admin Server Role
• Database Creator Server Role

Working on SharePoint technologies on a daily basis, yet small things sometimes slip thru my mind

I am working on automating the process of deploying a SharePoint farm. The client wants a standardize way to setup all the development and test environments. So looking into automate SharePoint deployment thru scripting seems the right way to go.

Being a scripting newbie/dummy, luckily there are already a number of good resources to provide me the information I need:

Ben Curry has a very detailed blog on how to script SharePoint farm using PSCONFIG.exe and STSADM.exe

Technet has all the references I need when I am unsure of a command line tool

The 3 command line tools I need to use are SETUP.exe, PSCONFIG.exe and STSADM.exe

SETUP.exe - Install the binary bits. Uses a Config.xml as input parameters (e.g. install location, product key, server type)

PSCONFIG.exe - equivalent to running the SharePoint Product and Technologies Configuration Wizard, create/connect to a config database, create Central Administration web applicaation, install services and features to the environment

With PSCONFIG, one can also have the option to specify the farm's configuration database name instead of some GUID attached to it. Also, note that there is sequence of running the PSCONFIG commands.

1. configdb

2. helpcollections

3. secureresources

4. services

5. installfeatures

6. adminvs

7. evalprovision (only for stand-alone installations)

8. applicationcontent

9. upgrade

STSADM.exe - start search services and create Shared Services Provider

And just for scripting newbie\dummy, if you need to use the syntax "%" (percentage sign) inside the scripts as a text, use double %% syntax for the display of character "%". --> this happens to be the longest time I spent on troubleshooting my script.

Every once in a while, I am debugging a webpart on SharePoint and all of a sudden, the page broke. The error message on the page is "An unexpected error occurred" which tells me nothing other than the fact that it's an error.

To turn the not-at-all-helpful error message into a meaningful one (meaningful for the development environment), 2 easy changes in the web.config file:

Another error message sometimes I get is "one or more of your webparts is causing problem. Close the webpart(s) in the maintenance page". This is better than the last error message as I can at least close/delete the trouble making webpart(s).

Today, I need to do webpart debugging and I want to have access to the maintenance page. How? Short and easy to remember, just append "?contents=1" to the page URL.

For example,

http://servername:portnumber/sites/abc/pages/default.aspx?contents=1

Been away from the SharePoint world for 3 months and a lot of information missed out (wow *o* !)

A very COOL silverlight site for .NET developers to learn SharePoint

Disposing SharePoint Objects from Chris O'Brien

VHDs from Microsoft TechNet mentioned by Joel Oleson

I am sure there are lots more that I have missed......

Recently, I need to write a utility tools that handles moving documents (or aspx pages in a site) within the same site or accross site collections. The WSS 3.0 object model provides classes that would do that easily in code.

I use the methods in SPFile class to do a copy/move operation since the source and destination locations are in the same wss site.

SPFolder srcFolder = web.GetFolder(srcFolderName);
SPFileCollection collFiles = srcFolder.Files;
collFiles[index].CopyTo(destFolderName + "/" + collFiles[index].Name);

web.dispose();
site.dispose();

To copy files across site collection, I use the SPFileCollection class:

The standard answer is 3 times the size of your database.

To be more exact, how much disk space is consumed when doing gradual migration for a site collection?

When running test migrations, the following pattern is observed (assuming each site collection sits in its own content database):

For example, if the site collection is 10 GB, the temp database will be 25 GB and the final target database will be around 12 GB. The log files might take up to 36 GB for both temp and target database.

1. stop the OWSTIMER.exe
2. navigate to the file cache location
3. delete or move all the files inside
4. start the OWSTIMER.exe
5. file cache will be populated with the correct information from the config db
6. repeat above steps on all the servers in the farm with OWSTIMER.exe

After re-creating the config cache, Central Administration web application is showing correct values again ......

Knowing the importance of the OWSTIMER cache, I did some google quickly and find some resources about the SharePoint cache:

JOPX on SharePoint 2007 - Clearing the SharePoint Configuration Cache

Office Online - Configure Object Cache Settings

In migrating a site collection (not the portal root) of 40GB, the reverts never worked. The reverts timed out and it's this 'hang in the middle situation' where you still see the site collection listed in MOSS 2007 central administration but you cannot see its associating information (such as which content database it resides in). Of course, you also cannot see the site collection among the ones ready to be migrated in the "Select site collection to migrate" page.

This happened in one of the trial migration runs. Rebuilding the dev environment would be too time consuming because it involves migrating the portal first to get back to the state prior to migrate the specific site collection.

 So......

This discovery was by accident:

Before doing all these, you should check the "Database names" page for migration status, all the target databases are listed as read only

1. Disassociate the PAIR database (which contains the migrated portal) from the sharepoint farm in CA --> Application Management --> Content Databases
2. Re-associate the PAIR database to the sharepoint farm (that cleans up the 'bad' site collection associated with the web application)
3. Goes back to the site collection upgrade status page in CA --> Operations
4. Click "continue to upgrade" link next to the URL for migration
5. Click "database names" inside the Actions menu area located on the bottom left hand corner of the page
6. You can enter a new target database name for the orginal content database (change from read only to textbox for editing)
7. Click "Save" and wait for the operation in progress page to finish (If you don't give it a new name for target content database, it will create a new database with guid attached to it)

When you go back to the page that shows a list of site collection to be migrated, select the new target content database in the dropdown box and you see that all the un-migrated site collections are there (including the one that stucks in the revert process!)

One thing to note:
By associating to a new target database, there is no more options to revert those migrated site collections in the old target content database. But in my case, the reverts never worked anyway.  

In doing a migration which involve a custom site definition with custom document library/list, I follow the documentation from Microsoft which tell me to create a feature for the custom doc lib/list and use a upgrade definition file to document the mapping from the old (2003) location to the new feature location. Since I don't want to write out the feature definition on hand, I decided to use the SharePoint solution generator and deploy the feature to the farm; test the feature on a 2007 test site and check that everything is working. Next, create a upgrade definition file to include the custom site definition and *remember* to do the file mapping for the new feature, DONE.

Start the migration process and wait..... Migration operation completed successfully.

Now, navigate to the migrated site, everything looks good in the 2007 look and feel, the custom doc lib and the list data all seems to migrate successfully (looking from view all site contents page), try clicking on the custom doc lib/list link from the view all site contents page, and an ugly exception shows up on the page:

Exception from HRESULT: 0x81070215

Looking at the uls log file show the following:

#20015: Cannot open "schema.xml": no such file or folder. 
11/28/2007 11:40:15.07  w3wp.exe (0x08A0)                        0x04B8 Windows SharePoint Services    General                        72k7 High     (#2: Cannot open "schema.xml": no such file or folder.) 
11/28/2007 11:40:15.07  w3wp.exe (0x08A0)                        0x04B8 Windows SharePoint Services    General                        72k9 High     Failed to retrieve the list schema for feature {BD0EFB99-F17D-4EAF-B1CB-68D9D9DF5A5B}, list template 197; expected to find it at: "". 

Use the filemon.exe tool to capture the above process and find the following log:

4:46:26 PM w3wp.exe:5972 OPEN C:\WINDOWS\system32\inetsrv\schema.xml NOT FOUND Options: Open  Access: Read 

After copying the feature's schema.xml to the above location, repeating the above process gets me to the webpart maintainenance page instead but the only webpart on the AllItems.aspx is the normal ListViewWebPart.

...... after many many hours of unsuccessful attempts to solve this problem, finally found out it's the feature that originates all these troubles, by default, the solution generator creates the feature with its normal list template type id (located at the elementmanifest.xml) and list template id for document library is 101, contact list template is 105 etc. But the list template id for the custom doc lib/list in 2003 environment is using its own type such as 888, 999. This type id has to be matched in the new features too.

After changing the feature's list template type id to match to its own old version, navigate to the AllItems.aspx page of the custom doc lib/list gives me exactly what I want :)

[update on 3/11/2008]

In SPS 2003, when using custom list/doc library in site definition, you give it a unique list template TYPE id (e.g. '199') in the onet.xml file:

<ListTemplates>    

</Elements>

The feature ListTemplate TYPE id must be '199' in this case to match up with the old version in SPS 2003. 

.... registration is open now..... (But where is the agenda ?)

I was trying to find out the list of security accounts needed to prepare a multi server farm deployment for a client (1 SQL, 1 APP, 2 WFEs). After numerous research, I decided on using 6 accounts as the minimum (all domain user account). Here is the list:

• a setup user account (member of the administrators group on each server in the farm; SQL Server login; member of the securityadmin and dbcreator SQL server role)
• a database access account (also called the farm owner account)
• a SSP app pool account (I also use this account as the SSP service account)
• a search service account (for both MOSS search and WSS search)
• a content access account (for both SSP search and WSS search content access account)
• a general application pool account (for MySite and the 1st SharePoint site to users)   

Based on technet, all accounts are least privileged, except the setup user account because you need the administrator rights to perform installation and configuration. So I ran the install and configuration on all the servers, create a site collection and everything runs perfectly.

Then, I used the STSADM tool to run a backup of the environment, got the "cannot access database using login [setup user]" error. I went inside SQL Server and indeed, setup user doesn't have access to all the content databases. It makes sense for security reason, so I went on to run the STSADM using the database access account (farm owner account). "Access denied" message this time. I check that both the SQL server machine and the APP server has write access to the backup folder, so I was confused and lost.

After several more attempts, I finally discovered that it's my farm owner account who doesn't have access to use STSADM (at all!) even though it is a member of the WSS_ADMIN_GROUP on the servers. And the farm owner account needs to be a member of the administrators group to RUN STSADM!!!! 

So, what do I get from this finding? Well, while some resources said that you don't need the server farm account in the local administrators group, it's only partially right. You don't need this for "installation and configuration" but you definitely need this for doing backup and restore. (And you can use the setup user account for running OTHER STSADM commands...)