...Me Unplugged... : WSS

SharePoint 2007 Maximum Limitations

Harshawardhan Chiplonkar — Wed, 21 Mar 2007 20:50:00 GMT

Following is a list of names and other parameters with the maximum allowable size on each.

Entity                        Max Permissible Size
Site Name                    128 characters
Site URL                 255 characters
Display name                 128 characters
Connection string                 384 characters
Email address                    128 characters
Version numbers                064 characters
Virtual Server Friendly Name            064 characters
SQL Database Name                123 characters
SQL Database Column                128 characters
SQL Database Table Name            128 characters
SQL Role Name                    128 characters
Server Name                    128 characters
Windows User Name                300 characters
Windows Password                300 characters
Dependencies per object            032 objects
Zone enumeration value            004 zones
Default SQL command timeout             300 seconds
Number of simultaneous
workflows that can be run*             015

If during your course of using the product, you inadvertently cross these limits, then you would end up with errors. These are hard limits.

* This is the maximum number of simultaneous workflows that can be in memory executing code. (NOTE: there is no limit to the number of workflow instances in progress in the database)

~harsh

Single SignOn Error codes and what they mean

Harshawardhan Chiplonkar — Wed, 21 Mar 2007 03:41:02 GMT

Error Code	Meaning	When Thrown	Bubbled Behavior	How To Overcome
-2140993974	SSO is not configured	Failure when SSO has not been setup via Central Administration	Critical error logged in ULS with error code.	If SSO is not configured then configure from Central Admin.
-2140993973	SSO Wrong Version	SSO config setting or master secret has changed and change has not reflected.	Critical error logged in ULS with error code.	Not applicable. Self healing error.
-2140995575	Failed to connect to SQL Server	Creation of the SSO database fails.	Critical error logged in ULS with error code. Error logged in application event log.	Check SQL connectivity. Check permissions for the account running the MS SSO service.
-2140995576	SharePoint Central administration virtual root not found	The SSO folder under 12\Template\Admin\SSO does not exist. This check performed while configuring master secret server. Either a call into Configuration.ConfigureSecretServer via OM or the UI page to configure SSO can throw this error.	Error logged in ULS with error code. Or error returned to calling function	Repair the product installation. Most likely the files were not copied properly
-2140995588	Web application not running with windows authentication.	When a custom webpart is placed on a page in a non-windows auth web app. SSO CANNOT WORK WITH FORMS AUTHENTICATION.	Error logged in ULS with error code. Or error returned to calling function.	Check authentication providers for the web application. If you have a requirement to have the web app behind FBA, then SSO cannot work.
-2140995589	SQL Server not supported.	If the SQL server specified to host the SSO db is not greater than or equal to SQL Server 2000 SP3.	Error logged in ULS with error code. Or error returned to calling function.	Check SQL Server patching and version numbers. http://support.microsoft.com/kb/321185 Minimum required is SQL Server 2000 SP3
-2147023143	Failure to connect to the Microsoft Single-SignOn Service.	Failure to connect to the MS SingleSign On Service. Either when the service is not started or the service has a logon failure.	Error logged in ULS with error code	-

The above information is indicative of the errors that you may encounter while working with Single SignOn on MOSS 2007. This is only for troubleshooting purposes.

~harsh

Musings...

Harshawardhan Chiplonkar — Tue, 27 Sep 2005 04:38:00 GMT

Its been quite some time since I consciously dug out time to write something here. The past couple of months have been a helluva time. I started with getting the feelers on office 12 and then the whole bunch of technological challenges that throws up. Most of my time has been spent just getting to know the "stuff under the hood" and then some. The PDC was one big event this year from a technological perspective. This year saw the unvieling of Office 12 suite of products along with the much awaited Avalon, Acrylic and the WinFX showcase. But of course there have been reams and reams of HTML being churned out on everything post PDC.

Then on a more realistic front was the threat posed by Katrina and Rita - the current celebrities. Katrina was an eye opener on what happened and waht could have been done to prevent the debacle. But as always, when calamity strikes, human nature comes to the fore and we see astounding acts of heroism and selflessness from unexpected quarters. I was fortunate to have witnessed this in the recent cyclonic floods in Mumbai. With the water level rising upto 2 storeys, the situation was frightening, and yet the effervescent spirit of the die-hard Mumbaikar (as Bombayites fondly call themselves) kept hem afloat!

September is a month that I have grown to love. Giving me two opportunities to celebrate first with my birthday followed closely by my wedding anniversary. This time around was a bit special since it was my first anniversary. Celebrations galore!!! It was a lovely weekend which was whiled away reminescing on memories of our college days. Ecstatic.

I have been painstakingly trying to get the Office 12 beta working on top of Longhorn and its been hoodwinking me everytime. Aw well, atleast I have the satisfaction of seeing them in action as well as taking up the challenge to troubleshoot. With lots of work happening with .NET as well as the impending release of the much awaited .NET vNext, I thought it a good opportunity to start learning the ropes for that. With loads and loads of new features as well as new idealogies, its turning out to be quite an interesting ask.

On a lighter note had dekko of the AoE3 demo, with astounding graphics I personally feel the game play has slowed down a lot. Then of course there was the much raved about F.E.A.R - designed to chill we folks had the misfortune of the game crashing on us owing to poor hardware. Tsk tsk!

More coming soon....

Its here! Its here!

Harshawardhan Chiplonkar — Mon, 12 Sep 2005 23:33:00 GMT

After months and months of anticipation the word is out on the streets regarding the WSS SP2. Yoooohoooo! Check out more stuff here at: http://www.microsoft.com/downloads/details.aspx?familyid=abba20f2-3625-4c9c-a412-ab9bbebdb5e8&displaylang=en.

Listless

Harshawardhan Chiplonkar — Thu, 04 Aug 2005 21:58:00 GMT

This is something really silly. Any list that is a part of a site can be accessed by using a small snippet that looks more or less like this:

SPSite site = new SPSite(http://localhost");
SPWeb web = site.OpenWeb();
SPList list = web.Lists[index];

Now lets say you want to add an item to an ordinary list. The snippet would go like:

web.Lists[index].Items.Add(..some parameters...);
..add the values for the individual fields...
web.Lists[index].Update();

If, however the list in question turns out to be a document library then you will be pleasantly surprised to see that the file you just added is nowhere to be seen. The catch lies in that a document library also supports folders. So the modification becomes:

web.Lists[index].RootFolder.Files.Add(..some parameters..);

The parameters in this case are the byte array containing the content of the file and the destination URL in terms of the root folder of the document library.

Funny!

/Harsh

Trustworthy!!

Harshawardhan Chiplonkar — Wed, 03 Aug 2005 01:51:00 GMT

The other day I landed on a very interesting issue. Before I break in the solution, let me just try and explain the problem the way it came in.

Well, there was this guy who had created a custom web part to fetch a report from some database. He was supposed to be using a SQL database in production, but due to some reason, he had to make do with an Oracle database in test. The web part was using the ADO.NET ODBC and SQL data objects to establish connection and perform data retrieval. The problem as he accounted to me seemed to occur only when he used the SQL objects. Whenever he used the SQL objects and deployed the web part, and then dropped it onto a page, the action took him to an error page which asked him to go to the Web Parts Maintenance page and remove the web part. But if he went back to the drawing board and replaced the SQL objects with the ODBC objects, the same behaviour did not reoccur. His question, do we know this as a bug.

As a good support fellow, I asked him to share his web part. A reproduction was in order. And as I expected, there was nothing darn wrong with his poor little web part. But something was definitely going amiss. I recounted his demonstration of the problem. He was using a setup and deployment project and using the stsadm command line to deploy the web part. On the other hand, I as is widely done in PSS, used the Install Assemblies tool to deploy the web part. So faithfully, I sent the whole thing back, and asked him to use the Install Assemblies tool. A simple GAC deployment worked wonders. Not only did the error go away, but it also, succesfully fetched the results. I was elated. On closer investigation, the problem focus moved from ADO.NET data objects to the install location. As all of us know, there are two locations where one can deploy a web part assembly. One in the GAC the other in the assembly bin folder. These two locations behave quite differently from each other and result in a wide array of different outcomes.

The GAC is considered as a fail-safe option, where anything and everything will run without any issues. The bin folder on the other hand requires a practiced hand and a keen eye to tweak the settings. So the preferred location for a web part always tends to be the GAC. This is because the GAC enjoys a fuller trust level than any other location. Now in this case, it was a requirement to deploy to the Application bin folder. So the workaround would be to tweak the web.config file at the portal root and change the security trust level to 'Full'.

But it couldnt be so simple. This guy now wanted to not change the trust level for the entire portal but only for the particular assembly. Possible? Lets see. In the web.config you would notice that there is a path mentioned pointing to a different config file. Now, there are three config files for WSS_Minimal,WSS_Medium and Full. So the solution looks like adding the safe entry for the assembly into the particular .config file. Needs to be checked, but lets see how it goes.

/Harsh

Area 51

Harshawardhan Chiplonkar — Tue, 26 Jul 2005 04:00:00 GMT

This started of as another one of those weird things. Well, so here goes.
Problem: Accessing the news listing through the Object Model.
Solution:
       // get the reference
           SPSite site = new SPSite(“http://localhost”); // this will point to the portal URL
           SPWeb web = site.OpenWeb();
           // get the context
           PortalContext context = PortalApplication.GetContext(site.ID); // context got using the site GUID
           Guid newsGuid = AreaManager.GetSystemAreaGuid(context, SystemArea.News);

           // SystemArea.News is a Sharepoint enumeration already available through the API
           Area newsarea = AreaManager.GetArea(context, newsGuid);
           AreaListingCollection newscoll = newsarea.Listings;         // fetches all listings that are part of the current area

           for(uint i=0; i<newscoll.Count; i++)
           {
                 WriteToFile(newscoll[i].Title + “ “ + newscoll[i].Description);   //WriteToFile is a custom function used for debug logging to a file

}

And voila!

/Harsh

Digging the content index

Harshawardhan Chiplonkar — Thu, 30 Jun 2005 01:16:00 GMT

The content index is one of the most sought after parts of Sharepoint. Search is one of the most popular and also one of the most mystical of Sharepoint features. So it goes without saying that accessing the content index is like chasing a dream. But before you start jumping with glee, there is absolutly no way of directly accessing the content index. Though the object model does expose a certain surface area of the content index. I can infact point out that the content index is actually on the filesystem on the Sharepoint server machine. But thats about it.

Lets have a look a what the object model has in store for us. There are a couple of namespaces that spring forth from the Microsoft.Sharepoint.Portal.Admin.Search.dll that can help us scratch the surface of the content index.

The objects that are of interest are SearchSite, SearchCatalog and SearchContentSource.

using Microsoft.Sharepoint.Portal.Admin.Search;

//the using directive to get the above objects

SPSite site = new SPSite("http://localhost");

SPWeb web = site.OpenWeb();

SearchCatalog catalog;

SearchCatalog anothercatalog;

SearchContentSource contentsource;

System.Collections.IEnumerator anEnumerator;

System.Collections.IEnumerator anotherEnumerator;

System.Collections.IEnumerator yetanotherEnumerator;

SearchSite srchSite = new SearchSite();

srchSite.Connect("blr2r02-12",site.ID.ToString());

// takes <server_name>,site GUID

// this is gonna give you all the catalog names -

// btw you have to use the IEnumerator, no way out of it :-)

anEnumerator = srchSite.Catalogs.GetEnumerator();

while(anEnumerator!=null)

{

anEnumerator.MoveNext();

catalog = (SearchCatalog)anEnumerator.Current;

// here you can write out the catalog name using catalog.Name

WriteToFile(catalog.Name);

// WriteToFile is a custom function to output a string to a file

// lets try to write out all the content sources that are part of each catalog

anothercatalog=srchSite.getCatalog(catalog.Name);

// get reference of a particular catalog

// this is gonna give you all the content sources -

// again no escape form the IEnumerator

anotherEnumerator = anotherCatalog.ContentSources.GetEnumerator();

while(anotherEnumerator != null)

{

anotherEnumerator.MoveNext();

contentsource = (SearchContentSource)anotherEnumerator.Current;

// here you can get various properties like

// depth, display name, source group, URL, etc

WriteToFile(contentsource.Depth.ToString());

WriteToFile(contentsource.DisplayName.ToString());

WriteToFile(contentsource.SourceGroup.ToString());

WriteToFile(contentsource.Url);

// Now this is where we run into issues. BIG issues.

// There is no object returned by any of the methods or

// properties of the SearchContentSource class.

// All the return types are base data types. What does this

// translate to? This basically means that this is the end of the road.

// This is all the level of detail

// that you can get from the object model.

// This thought not much is still quite substantial to increase

// our information of the content sources.

}

So now what are the resources that can be helpful here? Lets see, the standard Sharepoint Portal Server SDK is a big help. If you dont already have it, heres where you can get a copy all for yourself. The Sharepoint Portal Server SDK

And heres where you can get the Windows Sharepoint Services SDK

Now, what about the class tree? so here is the PortalAdminSearch namespace

Happy hunting

Programmatically adding a List with custom fields

Harshawardhan Chiplonkar — Tue, 28 Jun 2005 02:31:00 GMT

When a list is created programmatically using a custom template, the custom fields do not get displayed in the UI. These fields do not become a part of the displayed fields of the default view.

The Problem - A common task like uploading a file to a list that was created programmatically using a custom template.

When you try creating the list using the Object Model, you would most likely get a “Exception Occurred’ error. But still the list would get created but without the custom fields.

On trouble shooting you would find that the while picking up the custom template the schemaXML for the template was not being populated. Theoretically, the schemaXML should have contained the definition for the custom fields. However the schemaXML property would throw a SPException.

This is why the code was throwing the error “Exception occurred”, and even though the list was being created the fields were not being created. The resolution in this case is to modify the schemaXML property to ensure that the fields are created.

The first line of attack is to modify the schemaXML property through string manipulations to get the property set and the list getting rendered properly. This is possible for the SPList object but not for the SPView object (schemaXML is readonly for SPView). By doing this, I was able to get the fields added, but they were still not being displayed.

Modifying the schemaXML to include “Hidden=’false’” or for that matter “Hidden=’FALSE’” did not help.

The solution that did work was as follows

- create a new list using a blank template

- programmatically add the custom fields to the new list

- Update the list to commit the addition of the new fields

- Create a new view based on the default “All Items” view

- Add the same custom fields to the new view

- Delete the original view

- Make the custom view as the new default view

Code Snippet

SPSite site = new SPSite("http://localhost/sites/Sergey/default.aspx");

SPWeb web = site.OpenWeb();

SPListCollection coll = web.Lists;

SPListTemplateCollection tmplcoll = web.ListTemplates;

SPFieldCollection fieldcoll;

SPListTemplate temp = tmplcoll[0];

Guid gd = coll.Add("NewList9","NewList9",temp);

coll[gd].Fields.Add("Test1",SPFieldType.Text,false);

coll[gd].Fields.Add("Test2",SPFieldType.Text,false);

coll[gd].Update();

string defaultquery = coll[gd].Views[0].Query;

SPViewCollection viewcoll = coll[gd].Views;

Guid anothergd = coll[gd].Views[0].ID;

viewcoll.Delete(anothergd);

System.Collections.Specialized.StringCollection viewfields = new System.Collections.Specialized.StringCollection();

viewfields.Add("Title");

viewfields.Add("Test1");

viewfields.Add("Test2");

coll[gd].Views.Add("All Items",viewfields,defaultquery,100,true,true);

coll[gd].Update();

/Harsh

SPListItem.Update()

Harshawardhan Chiplonkar — Thu, 16 Jun 2005 17:14:00 GMT

Now thats a funny title. This is something I worked on quite recently. Consider a scenario where you are trying to access a number of lists programmatically. The issue I dealt with was concerned with lists in a recurring event of a metting workspace. But subsequent research revealed that this is a generic issue.
So, you are accessing lists programmatically. Amongst say four lists (list1, list2, list3, list4, for example) you fetch the properties list ID, etc of list1. Now, you decide to change say the ist name and fire a SPList.Update() . After this is done, you decide to see the details for say List3. Oops, what happened to list3 details you are actually seeing details of all the lists! You recheck your code..no, you are not missing the identifier for list3 so what went wrong here?
Here is what your code would look like

      SPSite site = new SPSite(strUrl);
      SPWeb web = site.OpenWeb();
      SPList list = web.Lists[strListName];

      // use SPQuery to query the list

      SPListItem item;
      SPListItemCollection items = list.Items;
      if(items.Count > 0 )
      {
         item = items[0];
         // make some changes to this item
         item.Update();
      }

      // use SPQuery to query the list again

Why the query does not return proper results has to do with the way the cache is refreshed. This being one of the mystical disciplines, not much is clear. But one thing we know, is after the first query (the one that returns incorrect results), all subsequent ones are going to return correct results.
A possible explaination is that when the update executes, it executes on the database and makes the changes. However, owing to performance considerations, the list details are already in the cache. So now, we have two copies, the one in the cache which is dirty and the other in the database. At this point the cache still doesnt know that the database has been modified. So the query that executes is going to just run through the cache and pull up all the data. What is still mystical is that it pulls up everything and not just the concerned list.
Another interesting bit here is it doesnt matter which list you update.
So now you try to put in a wait before the next query executes...still no luck! this being as mystical as it is, there is no guideline on when the cache is going to get refreshed. Now, we need a workaround. Fetch the details yourselves and hence update the cache. Simple?..yup it is simple.
Just add the following line after the update...

items = list.Items;

What this is going to do is fire a query internally to update the cache. This in effect takes care of the update problem and you are raring to go. Case closed!

--/H