File Upload/Download File Size Limits

SharePoint store all the uploaded documents in the database. Having a restriction on the file upload size is always a good idea. You can do this two ways,

1. Give a upload file size limit under general setting of the web application in the central administration.

2. Modify the metabase.xml file on the IIS server.

a. Before you can edit the metabase.xml file you must tell IIS to allow you to edit the file. In IIS, right click the name of the server and select properties. Check “Enable Direct Metabase Edit”.

b. Find the metabase.xml file located in C:\windows\sytem32\inetserv and open the file in Notepad.

c. Search for AspMaxRequestEntityAllowed and increase the value. The default value is 204800 (200K). Setting the value to 1000000 will allow 1 MB file uploads.

d. You may now wish to uncheck the IIS property called “Enable Direct Metabase Edit”.

To increase the file download size limit, repeat all steps above but in Step 3 find the parameter called AspBufferingLimit. The default download limit is 4MB.

Reference

http://stackoverflow.com

www.banmanpro.com

Disable Loopback Check to resolve “Crawl Log error: Access Denied” error in SharePoint

Issue
Windows Server 2003 SP1 introduced a loopback security check. This feature is obviously also present in Windows Server 2008. The feature prevents access to a web application using a fully qualified domain name (FQDN) if an attempt to access it takes place from a machine that hosts that application. The end result is a 401.1 Access Denied from the web server and a logon failure in the event log.

The trouble is there are also scenarios where this fix will break normal operations of SharePoint.

1. Search Indexing.
If you are hosting the WSS Web Application Service on your Indexer for the purposes of having a “Dedicated Crawl Front End” and avoiding a network hop. This is common in small scale “Medium Server Farms”. Because the Indexer is crawling itself, the crawl log will fill up with 401s and your content won’t get indexed.

2. Web Application “Warm Ups”.
If you are running a scheduled task or timer job to hit the Web Application to avoid the start up lag after an application pool recycle, the “warm up” will fail with a 401.

3. Custom Code using SharePoint Web Services.
If you have custom code, either in SharePoint or out with it that leverages SharePoint Web Services (such as using the ExcelService API) these requests will fail with a 401.

Workaround

If you are working on a development environment or on just a single MOSS box – go for it – disable it completely. You need to debug and test locally and it’s likely you don’t know what addresses you will use ahead of time. I as a matter of course disable the check as part of my sysprep build for all my development and test machines. I never hit the problem because my base image is all sorted as I want it. I recommend you do the same.

1. Login to the SharePoint server.
2. Click Start, click Run, type regedit, and then click OK.
3. In Registry Editor, locate and then click the following registry key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
4. Right-click Lsa, point to New, and then click DWORD Value.
5. Type DisableLoopbackCheck, and then press ENTER.
6. Right-click DisableLoopbackCheck, and then click Modify.
7. In the Value data box, type 1, and then click OK.
8. Quit Registry Editor, and then restart your computer.

However, for production environments, DO NOT DISABLE this feature. You are unpicking a serious security check of the OS. If that environment underwent a security audit by a competent security engineer, it would be flagged. You should add a list of addresses you wish to exclude. This makes your scenario work whilst retaining the security check.

1. Login to the SharePoint server.
2. Click Start, click Run, type regedit, and then click OK.
3. In Registry Editor, locate and then click the following registry key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
4. Right-click MSV1_0, point to New, and then click Multi-String Value.
5. Type BackConnectionHostNames, and then press ENTER.
6. Right-click BackConnectionHostNames, and then click Modify.
7. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
8. Quit Registry Editor, and then restart the IISAdmin service.

References

Microsoft KB 896861

harbar.net

mossgurus.com

nishantrana.wordpress.com

social.technet.microsoft.com article I

social.technet.microsoft.com article II

Migrating Sharepoint website to a new web server and database manually

To migrate SharePoint website to a new web server and database server I have successfully managed two approach. In this article I have discussed doing the migration manually. To see my other post go to Migrating Sharepoint website to a new web server and database using script.

1. Install SharePoint on the new web server you want to migrate to.

2. Run the configuration wizard to connect it to the new SQL server. If you are connecting to the same SQL server delete (I would backup first) the Admin Content and ‘MOSS_Config’ databases. The configuration wizard will recreate these.

3. Install the same updates and services packs as on the original server. I did this with SP 2007 SP2. Make sure you run the configuration updates after the service packs.

4. Restore your website content databases and your two shared services databases (SharedServices1_DB and SharedServices1_Search_DB for example). In my case I had only three web applications. Portal, MySite, and SSPAdmin or 5 databases all together(MOSS_Config, MySite, SSP1, SSP1_Admin, SSP1_Search). Don’t worry about the search database. You will have to recrawl your website anyway. Make sure the database names are exactly the same as they were orginally.

5. Recreate your web applications. My case they were portal, mysite, sspadmin. When you create them this is your chance to change a URL or a port number or enter a host header. When you get to the database name, put in a fake name such as WSS_Portal_DeleteMe. You will delete this database later. Do this for all your webapplications.

6. Next step is to remove the temp database from each web application and attach the real database you restored in step 4. To do this go to Central Administration -> Application Management -> Content Databases. Select the web application you would like to change. Select the database name (for example WSS_Portal_DeleteMe). Check the box in the next screen to remove content database. You should now see no database attached to the web application (it also remove it off the sql server). Select add a content database. For the database name put the name in EXACTLY as you restored it which should be EXACTLY like it originally was. Don’t worry about the Search Server field since you have not started that service yet. Do this for all your web applications. You now have three new web applications attached to your 3 restored content databases.

7. Start required services on new server. Go to Central Administration -> Operations -> Services on Server. Start the Windows SharePoint and Office SharePoint searches. Let it create a new database.

8. Restore your SSP (these are the other two databases you restored earlier). Central Admin -> App Management -> Manage this farm’s shared services (Click in the Shared Services link on the left!). Select Restore SSP. Name the SSP (Can use the same name as before SharedServices1 or change it. I would leave it so it matches the DB name) Make sure you select your SSPadmin and MySite web applications your created earlier and your restored database names. Do I have to mention again to make sure the names are exact! Select the index server (it is now available since you started the service). You will get a warning stating you are changing the association of the existing web applications. Click OK.

9. Install any 3rd party web parts or custom ASPX pages before you try and open the site so it does not mess with any formatting. In my case I to reconfigure AKS Toolkit and aRTE on the server. Install IFilter for PDF icon. Migrate all web.config changes manually. For e.g default proxy settings.

10. Open your SSP website and user import and then start a full crawl. You should notice that all your SSP settings are still there.

11. Since you did not restore the Sharepoint_AdminContent database you will have recreate things like smtp server names. These are all easy things that can be found off the main Central Admin Page. You should even go through the steps they list and complete each one.
You should now have a fully functioning SharePoint site on a new server with a new sql server.

Reference

http://www.endusersharepoint.com/STP/topic/restore-an-entire-farm-in-to-a-new-set-up

Back up and restore SSPs (Office SharePoint Server 2007)

Back up and restore an entire farm (Office SharePoint Server 2007)

Back up and restore Web applications by using built-in tools (Office SharePoint Server 2007)

Restore: Stsadm operation (Office SharePoint Server)

www.tzunami.com

www.metalogix.net