SharePoint with Attitude…

Never thought it would take me about an hour to delete a Record library…

I was trying to delete a Record library and the delete option is not part of the library site settings as with any other type of library or list.

This is the first time I work with Record libraries so I found it interesting. I tried using SharePoint Designer and got the error “List cannot be deleted”.  I was an administrator and the library had some documents so I thought maybe I had to delete first all documents and then try to delete it.

When trying to delete documents from the library and I kept getting this error: “The item cannot be deleted, moved, or renamed because it is either on hold or is a record which blocks deletion”

Turns out that when you create a Record library, by default it declares all items in the Library as records (which makes sense because it is a Record library right?), and a record cannot be deleted. So if you are planning to delete records from a Record library it is better to go to “Record declaration settings” (under the library site settings) and uncheck the “Automatically declare items as records when they are added to this list”.

If you however didn’t do this and want to delete an existing document record, go to “Record declaration settings” (under the library site settings), uncheck the “Automatically declare items as records when they are added to this list”, and check the “Always allow the manual declaration of records”.

By doing this you are now able to undeclared a record as a record, and then be able to delete it.

To undeclared a record:

Under the record context menu, select “Compliance Details”

You will see the status of the record, whether if it is on hold or not and wheter if it is a record or not. To be able to delete remove all any holds and “Undeclare record”.

Close the window and now try to delete the document; it will be deleted

Great! So the library is now empty and I still can’t delete it :S

Well, the job “Hold Processing and Reporting” takes care of scanning libraries to find records and to know what libraries what records or not. So we have to run this job for SharePoint to know that the library doesn’t have any records.

After running the job I go to the Library settings and the delete option is there!!! Finally!!!

Does SharePoint suck? No way!!, but with a client today, I got that comment from one of their developers.

I’ve heard that comment too many times, and every time I hear it I laugh way too much; mainly because it reminds me when I hated SharePoint too, yes I also thought that SharePoint sucked, but that was when I first started to work with it, long long time ago…

If you think about it, every time more and more companies are implementing SharePoint, why? because the business people see a value in it, they see what SharePoint can do to improve their businesses and operations.

Having more SharePoint implementations, requires more people working in SharePoint projects, and let’s be honest not too many people are really “SharePoint developers or experts”, most of the people working in SharePoint are .NET developers.

Which brings me to the question: who is usually the people complaining about SharePoint and saying that SharePoint sucks? the answer: the developers.

Interesting, why does this happen?, well it’s easy. SharePoint is based in .NET, and for many people is easy to think that if you know .NET then SharePoint will be easy for you.

The thing is, if you know SharePoint, then you know .NET; but if you know .NET it does not mean that you know SharePoint, yes it is an advantage, because it means you know the basics, but there is still a learning curve.

Usually developers are thrown into SharePoint projects just because they know .NET, without a previous training/knowledge of SharePoint. It means they will learn SharePoint on the road, and that learning curve can be painful (ask me! lol). It is usually because of the lack of knowledge in SharePoint that people say SharePoint sucks, because we wan to do things the way we are used to in .NET, and things that can be done in 5 min in .NET, take hours in SharePoint, so we get frustrated.Let’s not forget that SharePoint is a platform, it has its own way to work.

Now I’m not saying that doing a project in SharePoint is better than doing it in ASP.NET for example, or than doing it in ASP.NET is better than doing it in SharePoint, It just depends on the project, there will be projects where it is better to do it in SharePoint and other where it is not, SharePoint Architects play a key roll in here.

This, also brings a person to say that SharePoint sucks, when the sales people sale a project in SharePoint (because they just want to sale) without analyzing if it is convenient or not to do it in SharePoint, it will become frustrating for the developers to meet some requirements.  At the end the developers will be the ones working on the project that was not suitable for SharePoint and they will end hating SharePoint.

In conclusion, SharePoint is a very robust platform, and you have to know its architecture and go through that learning curve in order for you to be able to work in a SharePoint project and not get frustrated in the way.

After a couple of projects working with SharePoint, you’ll understand more and more about it, and I’m sure you’ll like it, and probably you’ll even love it! just like I love SharePoint.

Love not hate people!

This is a good info that everybody working with SharePoint should keep in mind:

The following values are recommended for an acceptable performance with SharePoint: 

• Web Applications: 99 per SSP
• Site Collections: 50,000 per web application.
• Zones: 5 per farm.
• Content Databases: 100 per web application.
• Web Sites: 250,000 per site collection. The recommended is 125 sites with 2,000 subsites each.
• Sub Sites: 2,000 per web site.

• Documents: 5 million per document library, over 2,000 elements velocity is slower to present the data in the page.
• Document Size: The default value is 50MG, it can be changed to support until 2GB.
• Lists: 2,000 per web site.
• Metadata: 256 per list.
• WebParts: 50 per page.

• Users in groups: 2 million per web site (using AD)
• User Profiles: 5 million per farm.

• Index Documents: 50 million per index.
• SSP: 3 per farm.

• 8 web servers for each Database server.
• 3 web servers for each domain controller.
• One index server per SSP.
• Servers for excel services: no limit.
• Servers for Queries: no limit.

• Workflows at the same time: 15.

  Site pages are those that support user customization by using tools such as SharePoint Designer. The downside of customization is that it affects scalability.

Imagine a large SharePoint environment with a Web application running thousands of sites. What would happen if the site administrator of each site modified the site’s home page with the SharePoint Designer? Every one of these site pages would become unghosted (customized). This would negatively impact scalability by forcing the front-end Web server to retrieve each page separately from the content database. Each page would also have to be individually parsed and loaded into memory.

Also consider the fact that once a site page has been customized, a copy must be stored in the content database. This brings up a security concern. Imagine a situation in which a malicious user who has been granted site administrator permissions within a site collection tries to mount an attack by writing in-line code within a customized version of a site page. This security concern is mitigated in SharePoint by having a default policy that prohibits in-line scripting in site pages. The default policy also runs site pages in a no-compile mode, which means they are not compiled into DLLs.

 The key point here is that customization support for site pages brings with it performance concerns and security issues.

Application pages avoid these concerns, they do not support customization.

 The standard Site Settings page (settings.aspx) is a good example of an application page. It can be accessed from any site, yet it does not support customization. Application pages are deployed as physical files on the 12 hive of the file system.

 Because there is only one version of an application page scoped at the farm level, it can be compiled into a single DLL and loaded into memory once for each Web application. Besides, application pages are not subject to attack from users who have permissions to customize site pages. So, SharePoint does not prohibit them from containing in-line code.

Application pages are used for administrative functionality in SharePoint