Difference between ghosted and unghosted and what does it mean anyway?

This question is often asked by our SharePoint students.  To keep it short and sweet, ghosted means not customized and unghosted means customized. 
I'm sure everyone knows by now that SharePoint stores web pages like .aspx and other items in a few different places. 

• The 12 Hive
• The Content Database
• IIS (in a virtual directory)
  • Some content in the 12 Hive
  • Some content nested under the InetPub folder

Well, let's say that there is a web page or other type of document that SharePoint uses that is stored in the 12 hive.  Like the default.aspx for example.  When it is first create during the install and placed in the 12 hive, it is considered to be ghosted.  An odd word for some that basically means that when the page needs to used it will be read from the folder somewhere in the 12 hive.  When your SharePoint site is created several entries are made in the Content Database (in SQL Server).  These entries tell SharePoint what Pages, List, Libraries, etc are associated with your SharePoint site.  But even though there is an entry in the database showing that your site uses the default.aspx page, it doesn't mean that the default.aspx page is stored in the database.  If you change the default.aspx (using SharePoint Designer for instance), you have customized the page and your version of the page will now be stored in the content database that stores the entries for that specific site.  The customized version of the default.aspx page is now considered unghosted for that specific site.
In other words, Ghosted pages become unghosted pages once a file has been modified.  There are several good reasons for this and there is more to the story. 

Difference between PowerShell and Stsadm in SharePoint

• Windows PowerShell is built on the Microsoft .NET Framework and accepts and returns .NET Framework objects. Hence, can interact with .Net objects directly.
• Here we use commandlets (cmdlet) instead of commands. Commandlet is a instance of .Net objects
• We can automate the tasks using power shell scripts.
• Windows PowerShell also gives you access to the file system on the computer and enables you to access other data stores, such as the registry and digital signature certificate stores.

Difference between webpart and user control in SharePoint I feel the most important difference is that the webparts supports personalization which means that changes in the personal view will be stored per user basis. Also as Rob said, the user has the freedom to add/remove as per his need. On the other hand a usercontrol is more of a kind of static one. So you need to provide a functionality that is not required to be added and removed every now and then.

Splitting large Content DB into multiple content DBs in SharePoint/MOSS 2007

Very Exciting. Getting ready to split up a large content DB on a large enterprise level moss farm deployment. The idea is to distribute data that has grown over time into multiple content databases for performance and reliability. The plan is to use stsadm -o mergecontentdbs. However this is known to have implications and issues - http://support.microsoft.com/kb/969242. We are taking all necessary steps to avoid any problems. I'll update this post later on how our operation does.
 Update - Sorry for the late update guys. heres how it went.
 We had 2 tasks ahead of us. One was to move a content db from one database server to another in the cluster. The other was to split up a large content db on one of the servers into multiple content dbs.
Splitting the large content db into multiple content DB's:
 Microsoft recommended that we do not run the merge content db command on databases larger that 10 GB in size. So instead of moving out the larger site collections into new content databses, we decided to move all of the smaller site collections out instead. This would take much longer, but would be safer so we went that route.

1. Make sure we stop all search crawls. This is important. Not pause but completely stop the search crawls. Let the running crawls complete and remove the schedule for all future crawls. If we do not do this, we take the risk of corrupting our search indexes.
2. Create the new content databses
3. Run stsadm -o preparetomove on the content db to be split
4. Create a sites.xml using stsadm -o enumsitecollections on the source content database
5. split up the sites.xml into manageable chunks containing the site colllections that we which to split out
6. run stsadm -o mergecontent dbs on the source and destination content databases using the site.xml files created in step 5 to move the site collections from source to destination database to the destination content databases
7. run stsadm -o databaserepair command on the source and destination databses to remove any orphan records - we had none
8. test

we moved approximately 150 GB of data from a large content database into 5 diffenet new content databases. It took us approximately 18 hours including testing. After the maintennance, we improved page response times for the site collections. We also reduced app pool recycles for our web applications due to processes hitting their virtual memory limits. These almost seemed to dissapear after the maintennance. Overall we were very happy with the results.
Moving a content db from one server to another:
We had multiple large content databases on one server and we wanted to balance it out by moving a large content database from one server to another in the cluster.

1. Run stsadm -o preparetomove on the content db to move
2. detach the content db by running stsadm -o deletecontentdb
3. using sql management studio, detach the content database from the server instance
4. move the databse files from the source server to the destination server
5. using management studio, re-attach the content database on the new sql server
6. add the content database by ising stsadm -o addcontentdb
7. Test

that was pretty much it. After our maintennance, we started our search crawls and reset the schedule. balancing out the databases also increased performance on our web applications.

Configuring BLOB storage in SharePoint2010

With Sharepoint 2010, the Remote Blob Storage (RBS) functionality, which allows putting documents into the database filesystem instead of the database itself, came into focus again. To make that happen each content database is located in a specific section of the file system where all the documents are stored. This documents are none the less managed by Sharepoint, a database is mandatory even if the documents are stored as BLOB because metadata is written exclusively into databases.

The following installation routines and steps to activate RBS are based on Technet and the blogs of Jie Li and Todd Klindts.

All the following installations have been done on Microsoft Windows Server 2008 R2 and Microsoft SQL Server 2008 R2 as there is no support for RBS on Microsoft SQL Server 2005.

First of all we have to activate FILESTREAM on the SQL instance that you want to put to the BLOB.

1. Connect to SQL Server
   Start –> All Programs –> Microsoft SQL Server 2008 R2 –> Configuration Tools –> SQL Server Configurations Manager
2. In the Services list, click “SQL Server Services”
3. Choose your SQL instance (here “SQL Server (MSSQLSERVER)”) and right click Properties.
4. Switch to the FILESTREAM tab and check all the available checkboxes
5. Click Apply –> OK
   
6. Now start SQL Server Management Studio
   Start –> All Programs –> Microsoft SQL Server 2008 R2 –>SQL Server Management Studio
7. Open a query windows and start the following SQL statement
   For easier reference, just copy the text below

   ---

   EXEC sp_configure filestream_access_level, 2
   RECONFIGURE

   ---

This was the first step, FILESTREAM is now successfully activated.
All further steps requires SharePoint to be installed properly and that a WebApplication has already been created. The Content Database in this case I created by Powershell:

1. Connect to a Front End Server Start –> Microsoft SharePoint 2010 Products –> SharePoint 2010 Management Shell Create a Content Database
   For easier reference, just copy the text below

   ---

   New-SPContentDatabase –name WSS_Content_Blob_001 –WebApplication http://sp2010 –MaxSiteCount 1 –WarningSiteCount 0

   ---

Now the new content database (in this case “WSS_Content_Blob_001”) has to be prepared for use with FILESTREAM.

1. Connect to your SQL Server
   Start –> All Programs –> Microsoft SQL Server 2008 R2 –>SQL Server Management Studio

Open a query and execute the statement below. Replace “C:\Blobstore“ by your storage-path. The directory must not exist when executing the statement, otherwise an error will be given. For easier reference, just copy the text below

---

use [WSS_Content_Blob_001]


if not exists (select * from sys.symmetric_keys where name = N'##MS_DatabaseMasterKey##')create master key encryption by password = N'Admin Key Password !2#4'

---

use [WSS_Content_Blob_001]
if not exists (select groupname from sysfilegroups where groupname=N'RBSFilestreamProvider')alter database [WSS_Content_Blob_001]  add filegroup RBSFilestreamProvider contains filestream

---

use [WSS_Content_Blob_001]
alter database [WSS_Content_Blob_001] add file (name = RBSFilestreamFile, filename = 'c:\Blob_001') to filegroup RBSFilestreamProvider

---

Now the direcory for the Blobstore has been created in “C:\Blob_001”
Next you have to download the EXE for RBS, and it has to be copied to each Web Frontend Server. During all the following steps mind checking the log files for errors.

1. Connect to the Web Front End hosting the Central Admin Console
2. Open a Command Prompt (IMPORTANT -> run with elevated permissions)
   
3. Change to the directory containing the previously downloaded RBS_X64.exe
4. Delete or rename a already existing „rbs_install_log.txt“ if applicable.
5. Run the follwoing command, replace DBNAME with your content database and DBINSTANCE with your SQL instance. Mind that this command only works once, if you want to configure a second database, chose the option “Configure additional database” (see below).

   ---

   msiexec /qn /lvx* rbs_install_log.txt /i RBS_X64.msi TRUSTSERVERCERTIFICATE=true FILEGROUP=PRIMARY DBNAME="WSS_Content_Blob_001" DBINSTANCE="DC" FILESTREAMFILEGROUP=RBSFilestreamProvider FILESTREAMSTORENAME=FilestreamProvider_1

   ---

6. After this process has completed (it may take a minute or two, the log reads “Verbose Logging stopped”), check the “rbs_install_log.txt” if it contains the following line of text (it should be approximately 21 lines before the end of the file:
   

   ---

   "Product: SQL Remote Blob Storage -- Configuration completed successfully"

   ---

   
   If that is not the case you have an issue. Check the following:
   - Are you in the right directory
   - Did you make a typo
   - Did you run the prompt with elevated privileges
7. If you have more than one WFE in your farm, you now have to change to the other servers and run the following command:
   For easier reference, just copy the text below
   

   ---

   msiexec /qn /lvx* rbs_install_log.txt /i RBS_X64.msi DBNAME="WSS_Content_Blob_001" DBINSTANCE="DC" ADDLOCAL="Client,Docs,Maintainer, ,FilestreamClient,FilestreamServer"
   

   ---

8. Check the “rbs_install_log.txt” if it contains the following line of text (it should be approximately 21 lines before the end of the file:
   

   ---

   "Product: SQL Remote Blob Storage -- Configuration completed successfully"
   

   ---

9. Execute all steps from step 7 on every additional WFE. This is mandatory, otherwise problems might occur.

The script has created a few tables in the database, check if they are existing:

1. Connect to SQL Server
   Start –> All Programs –> Microsoft SQL Server 2008 R2 –>SQL Server Management Studio
2. Execute the following query
   For easier reference, just copy the text below
   

   ---

   use WSS_Content_Blob_001
   select * from dbo.sysobjects
   where name like ‘rbs%’
   

   ---

The result should show the RBS tables. This may take a while.
As one last step you have to tell Sharepoint that the content database uses RBS. To do that you have to execute the following command:

1. Connect to WFE
   Start –> Microsoft SharePoint 2010 Products –> SharePoint 2010 Management Shell
2. Execute the following commands in sequence:
   For easier reference, just copy the text below
   

   ---

   $cdb = Get-SPContentDatabase WSS_Content_Blob_001

   ---

   $rbss = $cdb.RemoteBlobStorageSettings

   ---

   $rbss.Installed()

   ---

   $rbss.Enable()

   ---

   $rbss.SetActiveProviderName($rbss.GetProviderNames()[0])
   

   ---

   $rbss

   ---

Since all has been prepared we can check the functionality. Just create a site collection and make sure the content database used is “WSS_Content_Blob_001”. (or whatever you chose during install).

1. Connect to WFE
   Start –> Microsoft SharePoint 2010 Products –> SharePoint 2010 Central Administration
2. Application Management – Manage Content Databases
3. Choose the applicable Web Application
4. Configure the Content Database to put the next site collection to “WSS_Content_Blob_001”
   – If you have multiple databases, set “Maximum Number of Site Collections” to the current value
   – “WSS_Content_Blob_001” should not contain any site collections
5. Go back to the main site of  Central Administration
6. Application Management – Create Site Collection
   - Enter all the required data
   - OK
7. As soon as the site collection creation is finished, all newly uploaded documents should be created in the filesystem.

Notice:

Documents below 100 kB will not be put to the file system but will be stored in the database.

Configure additional content databases:

If you want to configure more than one content database for RBS, all the steps above have to be executed. The only difference is the command in step 5. This one dies not work, and no RBS tables are created. Therefore use the command below:

---

msiexec /qn /i rbs.msi REMOTEBLOBENABLE=1 FILESTREAMPROVIDERENABLE=1 DBNAME=WSS_Content_Blob_002 FILESTREAMSTORENAME=FilestreamProvider_1 ADDLOCAL=EnableRBS,FilestreamRunScript DBINSTANCE=CD