SharePoint:Managed properties in Sharepoint

 Here are some examples of managed properties that are available in MOSS 2007,

• AssignedTo
• Author
• ContentType
• FileExtension
• SiteTitle
• etc..

SharePoint:Limits and details in Moss

For SharePoint Portal Server, here's an extract from the Capacity Planning whitepaper:
It is important to understand the ramifications of the different features and functions of the SharePoint Portal Server solutions to size the system so that the performance of the system is good.
The following table lists some of the SharePoint Portal Server objects and describes their recommended use. "Typical" indicates comfortable and well tested; "maximum" indicates that the system can support that number, but not without some performance ramifications or
special configurations.
An asterisk (*) indicates a hard limit; no asterisk indicates a tested or supported limit.

• Portal sites (full) - typically 2 ... maximum 15 *
• Portal sites (child) - typically 10 ... maximum 100 *
• Areas - typically 1,000 ... maximum 10,000
• Best Bets - typically 1,000 ... maximum 25,000
• Area depth - typically 5 ... maximum 20 *
• User profiles - typically 50,000 ... maximum 1,000,000
• Audiences - typically 500 ... maximum 10,000
• Audience memberships - typically 500,000 ... maximum 5,000,000
• SSO credentials - typically 100,00 ... maximum 100,000
• Search indexes - typically 3 ... maximum 32
• Content sources -typically 25 ... maximum 250
• Search scopes - typically 25 ... maximum 250 *
• Indexed documents per content index - typically 100,000 ... maximum 5,000,000
• Indexed documents - typically 2,500,000 ... maximum 20,000,000
• Thesaurus entries - typically 1,000 ... maximum 10,000
• Alerts - typically 50,000 ... maximum 1,000,000
• Team sites - typically 10,000 ... maximum 250,000
• Personal sites - typically 10,000 ... maximum 250,000

SharePoint:Administrations concepts and limits

I frequently get asked for SharePoint scaling limits so I though I would blog an entry I can refer people to.

First an extract from the Capacity Planning section of the Windows SharePoint Services Administration guide which answers general WSS limits questions:

None of these are hard limits enforced by the system. They are guidelines for designing a server that has good overall performance.

• Site collections (Database scope) 50,000 ... Total throughput degrades as the number of site collections increases.
• Web sites (Web site scope) 2,000 ... The interface for enumerating subsites of a given Web site does not perform well much
  beyond 2,000 subsites.
• Web sites (Site collection) 250,000 - You can create a very large total number of Web sites by nesting the subsites. For example, 100
  sites each with 1000 subsites is 100,100 Web sites.
• Documents (Folder scope) 2,000 ... The interfaces for enumerating documents in a folder do not perform well beyond a thousand entries.
• Documents (Library scope) 2 million ... You can create very large document libraries by nesting folders.
• Security principals (Web site scope) 2,000 ... The size of the access control list is limited to a few thousand security principals, in other words users and groups in the Web site.
• Users ( Web site scope) 2 million ... You can add millions of people to your Web site by using Microsoft Windows security groups to manage security instead of using individual users.
• Items (List scope) 2,000 ... The interface for enumerating list items does not perform well beyond a few thousand items.
• Web Parts (Page scope) 100 ... Pages with more than 100 Web Parts are slow to render.
• Web Part personalization (Page scope) 10,000 ... Pages with more than a few thousand user personalizations are slow to render.
• Lists (Web site scope) 2,000 ... The interface for enumerating lists and libraries in a Web site does not perform well beyond a few thousand entries.
• Document size (File scope) 50 MB ... The file save performance degrades as the file size grows. The default maximum is 50 MB. This maximum is enforced by the system, but you can change it to any value up to 2 GB (2047 MB) if you have applied Windows SharePoint Services Service Pack 1.

SharePoint:Patch MOSS / WSS with minimal downtime

I have found this perfect article on my friend's blog and as it is absolutely amazing, and very helpfull I decided to link it here.

Original can be found here: Dirk Van den Berghe SharePoint Blog


preparation tasks:
- create a custom App_Offline.htm file for showing a maintenance page  - Copying this file into the root location of each IIS website used by SharePoint Web Applications will show this message instead of the SharePoint content.
- create a batch file that conveniently copies the App_Offline.htm file to all Web Applications (make sure not to copy it to the Central Admin WebApp)
- create a batch file that conveniently deletes the App_Offline.htm file from all Web Applications
- create a batch file that detaches all content databases for all Web applications with the exception of the Central Admin and SSP Web Apps ( add stsadm -o preparetomove command before detach database if you are still running MOSS SP1 pre-Infrastructure Update)
- create a batch file that attaches the content databases

Now you can start with following steps..



Upgrade process:
1.  Make sure that the hardware load balancers stops the services for WFE1 and only uses WFE2 to service user requests. We have an internal procedure that allows for manipulation of the load balancer. Actually we simply need to stop a custom IIS web site on the WFE server which will cause the load balancer to failover to the second WFE automatically.
Availability Result: Users are still able to access SharePoint content through WFE2.
Timing result: this operation took 2 minutes
2. Install the binaries for your SharePoint upgrade on WFE1. In my case WSS SP2 + MOSS SP2 +  all SP2 versions of the WSS and SharePoint Language Packs and finally installing the June Cumulative Update for WSS and MOSS. When installation completes, reboot the server.
Availability Result: Users are still able to access SharePoint content through WFE2.
Timing result: this operation took 50 minutes
3. Simultaneously install the same binaries on the index server. When installation completes, reboot the server.
Availability Result: Users are still able to access SharePoint content through WFE2.
Timing result: this operation took 40 minutes
OK So far so good. So basically, at this point, I have installed the binaries on 2 servers and I still have 1 to go, which is WFE2 that is still serving the SharePoint sites. I have two possibilities to continue:
- option1: install the binaries on WFE2 and reboot
- option2: run the configuration wizard on the upgraded WFE1 or the index server.
Option 1 will take all the sites down, because the installation of new binaries will stop IIS = Downtime and 404 errors. I cannot redirect my users to the upgraded WFE1, because the configuration Wizard has not run yet. So I am working with option 2
4. on WFE2 I launch my script that sets all my sites in maintenance mode (copies the App_Offline.htm file, that is)
Availability Result: Users are not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance through WFE2.
Timing result: this operation took 1 minute
5. on WFE2 I launch my script for detaching all content databases
- this script launches a stsadm -o preparetomove command for each content database (except Central Admin and SSP databases). This command is no longer required if you have at least SP1 with the Infrastructure Update installed.
- this script launches a stsadm -o deletecontentdb command for each content database (except Central Admin and SSP databases)
Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance through WFE2.
Timing result: this operation took 5 minutes ( I had 5 content databases)
6. on WFE1, run the SharePoint Products and Technologies Configuration Wizard.
If the upgrade process fails, investigate the log specified by the wizard, but also check 12-Hive\LOGS\Upgrade.log and the default SharePoint ULS logs. I have already seen that the SharePoint logs are written to the 12-Hive\LOGS folder instead of the location you specified in Central Admin during this upgrade process. After the upgrade your specified Logging location is used again.
Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance
Timing result: this operation took 15 minutes
7. Now that the farm configuration databases have been upgraded, your WFE1 is ready to start serving users again as soon as the content databases have been reattached. So, on WFE1 I launch my script to reattach the content databases. If one the operations generate an error, you can find the specific error in the 12-Hive\LOGS\Upgrade.log file.
Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance
Timing result: this operation took 10 minutes.
8. Make sure that the hardware load balancers starts the services for WFE1 and stops the services for WFE2 to service user requests.
Availability Result: Users are again able to access SharePoint content through WFE1.
Timing result: this operation took 2 minutes
My upgrade status is now complete with regards to the SharePoint content. My farm is servicing users again through a single Web Frontend Server for the moment, but it is servicing which is my main concern at this point. I no longer have downtime towards my users. If you add up all the minutes, then I have had a downtime towards my users of 33 minutes, which can be considered a small downtime. Now I continue with the rest of the upgrade process.
9. WFE2 is free now to do with whatever I want since it is no longer included in the load balancer pool.
- first, I launch my script to deactivate the site maintenance which simply deletes all App_Offline.htm files
- Next, I Install the binaries for the SharePoint upgrade on WFE2 + Reboot the server
Availability Result: Users are able to access SharePoint content through WFE1.
Timing result: this operation took 50 minutes
10. While WFE2 is installing the new binaries, I can run the SharePoint Products and Configuration Wizard on the index server.
Availability Result: Users are able to access SharePoint content through WFE1.
Timing result: this operation took 6 minutes
11. Run SharePoint Products and Configuration Wizard on WFE2
Availability Result: Users are able to access SharePoint content through WFE1.
Timing result: this operation took 8 minutes
12. Final step: Add WFE2 back into the load balancer pool

Interview Question in SharePoint

http://programmingsharepoint.blogspot.com/2008/02/sharepoint-interview-questions.html

Sharepoint:Stsadm syntax for feature and webpart deployment

For Feature:

STSADM -o InstallFeature -filename HELLOWorldFea\feature.xml -force


For Webpart:

Stsadm -o addwppack -filename filename [-globalinstall] [-force]

SharePoint:Create a New Page Layout in SharePoint 2007 - Feature-Based

So the requirement presented to me for a client was to take an existing page layout and change a few of the properties to allow it to use some custom styles implemented at the site collection level. To do this, I needed to create a new page layout based on an existing layout, make this part of a feature and pull in all the bits and pieces necessary to deploy this as a feature. Finally, I had to deploy it to the client's testing environment.

Here is how I did it...

First, I was instructed that the Search Main Page was to be used as the starting point. A developer on my team told me the best way to go would be to load up SharePoint Designer, navigate to the appropriate document library and export the file. This didn't work. My requirement was to have the search web part already on the page, the same as the existing search main page. SharePoint Designer killed this web part tag so it came up empty.

Getting a copy of the page layout
1. Better is to go to the site collection you're starting with

2. Select "Site Actions" -> "Site Settings" -> "Modify All Site Settings"

3. Under "Galleries", select "Master pages and page layouts"

4. Find the page layout from the list and open its context menu, select "Send to" -> "Download a Copy"

5. Save the file to the solution location. We won't be using Visual Studio because its not necessary for this evolution.

6. Once the file is saved, reopen the context menu for the page layout file and select "View Properties".

7. Click on the Preview Image and when it appears, right click and save the image to the same location as the aspx file.

Now you have the basic aspx files you will modify and put back into SharePoint as a feature. Open the aspx page in an appropriate editor. I'm assuming you understand enough about aspx to do what you need to do. Make the appropriate modifications and save the file.

IMPORTANT NOTE: If you are like me, you have a desire to 'clean up' the file declarations so you can see what's going on. Don't do this. I haven't figured out why but when I introduced hard returns in the second line (the really long one) of declarations between <% %> sections, it bombed when I reimported it into SharePoint. A guy on the team here thinks there may be a checksum on that line to head off tampering. Dunno but I know when I leave it it works, when I touch it it bombs.

You can also use any editor (Paint.Net works) to change the page layout to look the way you want it to. Change the folder of this file to your feature folder + "\Images". It's required for the page layouts and master pages.

So you should have two files and a subfolder for your feature ready to go.

Now we need to set up the feature to deploy it.
1. Create two new files in any editor: "feature.xml" and "layoutfiles.xml"

2. Here are the contents of my feature.xml file:

 <Feature  Id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
     Title="Custom Formatted Search Page Layout by Jim"
     Description="Search page with customized style inclusions"
     Version="1.0.0.0"
     Scope="Site"
     Hidden="FALSE"
     xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
   <ElementManifest Location="layoutfiles.xml"/>
  </ElementManifests>
 </Feature>

2.1. Id is a new GUID you generate from Visual Studio.

2.2. Scope means the level where this will be used, not the level at which it becomes available for items below it. So "Site" scope means it will be installed at the site collection level and used at the site level.

3. Here are the contents of my layoutfiles.xml file:

 <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="CustomSearchMain" Url="_catalogs/masterpage" Path="" RootWebOnly="TRUE">
   <File Url="CustomFormattedSearch.aspx" Type="GhostableInLibrary">
    <Property Name="Title" Value="$Resources:spscore,SearchMainTitle;" />
    <Property Name="MasterPageDescription" Value="$Resources:spscore,SearchMainDescription;" />
    <Property Name="ContentType" Value="$Resources:cmscore,contenttype_pagelayout_name;" />
    <Property Name="PublishingAssociatedContentType" Value=";#$Resources:cmscore,contenttype_welcomepage_name#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF390064DEA0F50FC8C147B0B6EA0636C4A7D4;#" />
    <Property Name="PublishingPreviewImage" Value="~SiteCollection/_catalogs/masterpage/Preview Images/customsearchpage.gif,     ~SiteCollection/_catalogs/masterpage/Preview Images/customsearchpage.gif" />
    <AllUsersWebPart WebPartZoneID="TopZone" WebPartOrder="1">
     <![CDATA[
                     <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
                         <Assembly>Microsoft.SharePoint.Portal, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
                         <TypeName>Microsoft.SharePoint.Portal.WebControls.SearchBoxEx</TypeName>
                         <Title>$Resources:spscore,SearchBoxWP_Title;</Title>
                         <Description>$Resources:spscore,SearchBoxWP_Desc;</Description>
                         <FrameType>None</FrameType>
                         <AllowMinimize>true</AllowMinimize>
                         <AllowRemove>true</AllowRemove>
                         <IsVisible>true</IsVisible>
                         <Width>420px</Width>
                         <GoImageUrl xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/gosearch.gif</GoImageUrl>
                         <GoImageUrlRTL  xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/goRTL.gif</GoImageUrlRTL>
                         <GoImageActiveUrl xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/gosearch.gif</GoImageActiveUrl>
                         <GoImageActiveUrlRTL  xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/goRTL.gif</GoImageActiveUrlRTL>
                         <TextBoxWidth xmlns="urn:schemas-microsoft-com:SearchBoxEx">280</TextBoxWidth>
                         <SearchResultPageURL xmlns="urn:schemas-microsoft-com:SearchBoxEx">results.aspx</SearchResultPageURL>
                         <AdvancedSearchPageURL xmlns="urn:schemas-microsoft-com:SearchBoxEx">~Site/$Resources:cmscore,List_Pages_UrlName;/advanced.aspx</AdvancedSearchPageURL>
                         <ShowAdvancedSearch xmlns="urn:schemas-microsoft-com:SearchBoxEx">true</ShowAdvancedSearch>
                         <DropDownMode xmlns="urn:schemas-microsoft-com:SearchBoxEx">HideScopeDD</DropDownMode>
                         <ShouldTakeFocusIfEmpty xmlns="urn:schemas-microsoft-com:SearchBoxEx">true</ShouldTakeFocusIfEmpty>
                     </WebPart>
                     ]]>
    </AllUsersWebPart>
   </File>
  </Module>
  <Module Name="LayoutPreviewImages" Url="_catalogs/masterpage/Preview Images" Path="Images" RootWebOnly="TRUE">
   <File Url="customsearchpage.gif" Type="GhostableInLibrary"/>  
  </Module>
 </Elements>

3.1. I took most of this from a coleague and from the net. The CData portion gives you the embedded web part already in the top web part zone.

3.2. Notice the gif image parts of the xml. These are whatever the new name is for the gif you edited earlier.

3.3. Notice also the part that says: "contenttype_welcomepage_name". This means that your layout will appear under the "Welcome Page" templates when you go to use it in your site collection. I haven't found much about this on the web yet but I believe if you search on content types and master page libraries, you may find additional options.

Your feature is complete!

Now its time to deploy.
1. Copy your aspx, gif (in its folder) and 2 xml files to the server where you want to deploy and into a new temporary folder.

2. Copy from the temp location to the 12 hive \Template\Features\ folder.

3. Open a command line and run: stsadm.exe -o installfeature -name MyNewPageLayoutFeature -force

3.1. Use the -force option if you've already installed previously.

3.2. the -name value is the name of the folder where the your feature now exists in the 12 hive.

4. Execute iisreset

5. Browse the the appropriate site collection on your server and back to "Site Actions" -> "Site Settings" -> "Modify All Site Settings"

6. Under "Site Collection Administration" select "Site Collection Features"

7. You should see your new feature/page layout. Click to activate.

Use your new layout.
Now, when you go to create a new page, you should see your additional layout. When you select it, you should get your custom layout gif to show users what it will look like.

I can imagine really intricate uses of this for creating custom CRM dashboards or for magically including SilverLight applications in your system. Good Luck!