BDC Metaman, now on your browser

Yes, the Microsoft sharepoint team blog has a post about it here .
I have had some good feedback about the tool and it definitely is a good plus when you have such a thing accessible to site collection administrators (power users) via the web interface. The license cost for your entire farm is $3k.

KwizCom Products

We were researching on some of the key issues that sharepoint has and found that most of these issues were resolved by KWIZ. However, after about 3 months of using their products, we have faced some issues which I would think were a result of Quality control issues. I will list down the issues in chronological order and what we did to fix it.

1. We were unable to create new wikiplus site collections. When we did, we used to get an error message. Involved Kwiz to troubleshoot. Found out that there were some comments in the kwiz master page template that were causing the issue. hmm..
2. I was unable to access my SSP. Looking in the logs I found out that its not able to find the Kwiz dll. Why would it need it when I am trying to open SSP? Anyways, involved KWIZ in troubleshooting and they recommended installing on the app server as well. New addition to the deployment instruction set.
3. We were unable to create bullets in the wikiplus page. Received a new build that fixes this.
4. We were unable to create a new wiki page. THe createnew.aspx was missed out in the new build. Quality control issues...
5. Now we are unable to create new wiki site collections in a particular webapp.

The product is having so much issues. No doubt that the problems that KWiz fixes are very important, but I quality of products is not up to the standard.

Excel Services - open as a snapshot error

Consider this scenario - You have a site collection/subsite where you have enabled excel services and you want to deploy an excel web access webpart. So you go ahead, publish an excel file to a trusted location. Provide that URL to the excel web access web part and you are all set. Right? Wrong!

If you use the functions open in excel or open snapshot in excel, more likely than not you will get an access denied error. I also faced the same error and it was very puzzling because I was the site collection admin, site owner, the whole 9 yards. So I decided to go a little deep and found that to display the excel webpart, sharepoint uses dynamicimageprovider to provide content to this webpart. Everything ok this far, but the thing is that is somehow looks for the content under the root site collection layouts directory. So for eg. you site is http://webapplication/sites/site1/subsite, it is looking for content under http://webapplication/_layouts. How weird.

Anyways, this seems to be a problem with microsoft design with no documentation on this. There are two workarounds - One, use the excel web access webpart at the root level or Two, provide the people, who need the open in excel and open snapshot in excel functions, read access on the root site collection, i.e. http://webapplication.

Configuring MOSS for LDAP Authentication

Setting up forms based Authentication for MOSS is a way that you can allow external customers to login your MOSS sites or it also allows you to bind to your LDAP user store which is not AD. There were some challenges in setting this up but I want to lay down a post on how to enable this.

Our infrastructure is running on MOSS SP1. We currently have some web applications but are integrated via kerberos with internal AD. We wanted to bind one of our web application to our LDAP store (Tivoli Directory Services) and enable FBA. I wanted to create the web-app for the FBA users but internal AD users should also be able to use integrated authentication (NTLM) to get in. So that involves setting up one web-app and extend it to another IIS website on your webserver. So two IIS websites point to the same content, but different authentication and policies. You do not necessarily need to extend a webapp to enable FBA, but I just find it easy for internal users to login seemlessly. The steps are as follows

1. Create a webapplication which will be internal facing. This will be the webapplication that the internal folks will use with their default windows credentials. (say http://internal/)
2. Create a site collection in this webapplication for testing purposes.
3. On the central administration page - choose to extend an existing web application.
4. Make sure that the web application that is selected is http://internal/.
5. Give this extended IIS website a different host header which will distinguish it from the internal web app. For eg. external which makes the url http://external/
6. Map it to Extranet Zone.
7. Login to the server and take a backup of web.configs for central administration and the external web application web.config.
8. Modify the web.config as mentioned below.

We need to modify the web config for central administration as well as the extranet IIS website. Take a backup before these these changes. Open the web.config and locate the <system.web> element. Note the important attributes connectionUsername and connectionPassword. These attributes were made available as part of SP1. So, if you do not have SP1, the only thing that you can do is anonymous bind to the LDAP store. Copy the following configuration right below this element and save the files.

<membership defaultProvider="LdapMembershipProvider">

<providers>

<add name="LdapMembershipProvider" type="Microsoft.Office.Server.Security.LDAPMembershipProvider,
Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="server name" port="389" connectionUsername="DN of the user connecting to store" connectionPassword="********" useSSL="false" useDNAttribute="false" userDNAttribute="dn" userNameAttribute="uid" userContainer="user container" userObjectClass="inetOrgPerson" userFilter="(ObjectClass=inetOrgPerson)" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" />

</providers>

</membership>

Description of some attributes -

• defaultProvider - Name of the default provider. This needs to be unique and used in configuration in the central admin.
• name - This is name of the LdapProvider. To reduce confusion, this is named same as the defaultProvider because I have seen some sites mentioning to use the defaultProvider attribute in the UI and some saying to use the name attribute.
• server - Name of the server. We have used ip because the test LDAP does not have a dns entry.
• port - the port used by the ldap. By default this is 389.
• connectionUsername - the dn of the ldap user who can authenticate to the user store.
• connectionPassword - password of the user connecting.
• useDNAttribute - This is required to be false else logins may fail.
• userDNAttribute - the dn attribute of the user. It may vary for different stores.
• userNameAttribute - the user name attribute of the user. This can also differ.
• userContainer - The container within which users are present.
• userObjectClass - The class that the users instantiates.
• userFilter - The filter that will determine which users can logon.

Once these configurations are complete, sharepoint now has the information on which store to bind to and with what username.

1. Go to Application Management > Authentication Providers
2. Make sure that the right webapplication is selected. (http://intranet/)
3. Make sure that the Extranet Zone is selected.
4. Change the Authentication type to Forms. (We choose to do this step in UI. It is also possible to do this in web.config, but I prefer to do it here)
5. If you are not SP1 or above, this is the place where you enable anonymous bind by checking the check box.
6. Provide the membership provider name as in the configuration in web.config - LdapMembershipProvider. Click on Ok.
7. Now everything is set up. But we need a user to login to extranet side of the webapplication using FBA. There are two ways to do this. First, is to use the http://intranet/ to login to the site using integrated authentication and then add the FBA user. Second, Add the user using Web Application policies. I choose to do the latter but both are equally easy to do.
8. Go to Application Management > policy for web application. Click on add user.
9. Select the right web application and be sure to select the Extranet Zone.
10. Time for reality check - Provide the id of the user and resolve it. It should be underlined if everything is configured correctly. If it is not, then you need to check your settings in web.configs. Somethings amiss.
11. Give this user full control - this user will act as the owner of the external website.
12. Browse to the site collection that you created before, using http://external/ url. You should get a form login screen. This is a default MOSS screen which can be customized according to needs.
13. Provide the user credentials for LDAP and login to the website.

Thats all! You are now setup with two entry points to the site. You can now add other users who you want to access this external site.

Common Language Runtime detected an invalid program

This is the error that came up today with our medium level server MOSS 2007 farm. The user was trying a simple function - creating a view in a list or a document library. We tried to see eventlogs and 12/logs but that didn't give us much information. Eventlog had a general error and on researching that we found out that it is related to a .net framework 2.0 error and there was a patch released for that. I could not quite believe that it will solve this issue because this patch was about 2 years old. I noticed that I was not able to remote in to one of our two webservers.

We found out that the webserver had hung up because of memory limit reached. The page file was full. So we, increased the page fill limit to 4 GB by going to My computer > properties > advanced and performance properties. I did an iisreset which brought down the PF usage from 5.2 GB to about 2.4 GB. We tried again and the error disappeared. This is a temporary fix and we are planning to move the page file to D:\ and also increase RAM from existing 4 gigs to 8. Lesson learnt - monitor your PF usage and your peak should not exceed you RAM. If it does, consider expanding your RAM.

MS Site delete capture tool

We are working on the backup and restore strategy for our farm and the Microsoft whitepaper recommends the use of the MS IT site delete capture tool. The thing to remember is that the tool is not supported by Microsoft. I wanted to give this tool a shot as this looks like an excellent way to make sure that you have all your data till the point you site was deleted.

So I downloaded the tool and installed it in our pilot box. The installation is not a wsp, instead it is a group of directories that need to be copied in the features directory. Also you need to place its dll in your GAC and some config files in layouts directory. Once done, you run the stsadm to install the feature. You create a new list using a custom list template provided with the tool, that helps you manage the alert settings for the administrator. Everything went fine with my installation and the tool was up and running.

Now for some testing. The tool works well for sites and subsites. The way it works is it captures the delete event of the website and then before actual deletion it creates a backup of the site. For a site collection, it created a bak file within the main sites directory. For a subsite, it creates a folder named the site collection and a backup within that folder. For restore you need to execute the usual stsadm -o restore for site collections or stsadm -o import for subsites.

However, couple of things that you should know - The tool does not capture the user security settings. So you will need to make sure after a restore that the right users have access to what they need. Other thing is that it does not backup any of the Fab 40 application templates that microsoft has launched. This was a big factor for us to decide that this tool can not be used for our needs, because we do plan to use these application templates. Back to our sql backups...

Backing up a single web application and a farm

Having a backup and restore plan seems to be the most critical piece of any MOSS implementation that is often overlooked. I can not stress how important it is to figure out a plan before doing any major changes in your farm. While, there is ample amount of documentation on doing this - Nothing goes and puts it in direct terms which can be used. For eg, why is the syntax to backup a web-application and a farm are the same or what do all those spbr folders mean.

First of all, the stsadm.exe operation has the same capability as your sharepoint UI tool. In fact, the ability to use scheduling with stsadm makes me rate it above everything else. First lets talk about backing up from the UI. Here you go in Central administration, browse to operations and then click "Perform a backup". You then select the components that you want to backup and proceed. You will be asked a directory name which you provide. The size that you see that will be needed for the backup is worst case scenario. You almost always will end up with a lesser size backup(I was shown a size of 171 Gb, but my full back up was done in 60 GB). After clicking on finish this will create a backup of the farm for you. (Given that you chose the entire farm earlier).

Lets go inside the backup directory. Here you will see directories named spbr0001, spbr0002 (if you have more than one) and so on. Each directory represents one backup\restore component that can be acted upon. If you go inside the spbr0001 directory you will see a number of *.bak files and an xml file. The bak files are backups of different components within the farm that you backed up. The xml file actually will contain a listing of the nodes that have been backed up and the corresponding nodes. For eg, the web app 1 was backed up as 00000006.bak and its content db was backed up as 000000007.bak. Each of the nodes also contain some tags - such as and . This has a value of true/false. False means that these items were not marked for backup and can not be restored as well from this particular spbr folder. True means that those particular nodes can be restored. For a full farm back up you will see true's. Whereas, if you selected only one webapplication for backup, you will see true against only that webapp and content DB node.

Ok. So how do you restore this farm/webapplication? Pretty simple actually, you just go to back up to Operations and select "restore from backup". Here you provide the directory name where you backed up your content. This for some reason lets you select only the last backup you took. If there is a way to workaround this, I would be interested to know.

So lets get to the stsadm piece. I feel we have more control over how this works and therefore prefer it. The first step is of course to decide what you want to back up. Imagine the tree structure in UI and the selectable nodes. If you can not then fire the command
stsadm -o backup -showtree
This will show you the tree structure on your stsadm console and mark the ones that can not be selected inside []. To execute a full back up of the farm you just execute this -
stsadm -o backup -directory -backupmethod full
To backup a single web application execute this script -
stsadm -o backup -directory -backupmethod full -item eg "sharepoint - 21897"
This will create a similar directory with an xml file. Only the nodes corresponding to the item mentioned will have true against SPCanBackUp and SPCanRestore.

This actually helps while restoring. So if you have a farm level backup done and you want a farm restore, you can do it using this -
stsadm -o restore -directory -restoremethod overwrite
If you have farm level back up and you want to restore only a particular item -
stsadm -o restore -directory -restoremethod overwrite -item
So you really can restore a single web-app from a farm level backup if you want.
But if you back up only a single web-app, you can restore only a single webapp even if you don't give the -item option to stsadm. All attributed to SPCanBackUp and SPCanRestore. While using restore, if you are scripting this for a batch job, dont forget to mention the -suppressprompt -username -password attributes to the restore cmd. Refer here if you want more details. And lest I forget, if your backup operation gets hung at about 50% of your search index while backing up your farm, go to Operations - Timer Job Definitions and kill that Search Back up and Restore item or try to find a permanent fix here