Recently, I have been getting a lot of questions about what are the things we should consider before upgrading to SharePoint 2010. Here is my list:
- Ensure your environment is fully functioning before you perform an upgrade. No need to carry over any old issues into your new SharePoint 2010 environment
- Make sure you meet hardware requirements: 64-bit hardware, 4 cores CPU or better, 8Gb of RAM or better, enough disk storage, et cetera.
- Make sure you meet software requirements Windows Server 2008 SP2 or better, SQL Server 2005 SP3 or better, SharePoint prerequisites installed, member of Active Directory domain, and so on. Everything must be 64 bit.
- Plan browser support (IE6 is not supported) and Office client upgrade
- Get all your SharePoint servers to Service Pack 2 or later
- Run Pre-Upgrade check to identify potential issues that will prevent us from successfully upgrading to SharePoint 2010. Review the report. Fix the errors. Re-run pre-upgrade check utility. Repeat, if needed.
- Identify all customizations such as 3rd party webparts or look-n-feel changes. Make sure those will work properly in SharePoint 2010
- Backup all SharePoint databases. Seriously. Backup all SharePoint databases.
- Choose upgrade approach: in-place approach or database attach upgrade. Or hybrid approach.
- Test the upgrade process. Before you perform an upgrade in production environment, test the upgrade process and address any issues you found during testing
- UPGRADE all your SharePoint servers to SharePoint 2010 (finally)
- Evaluate the upgrade. Review logs, check update status troubleshoot issues and errors.
- Use Visual Upgrade to convert site collections to the SharePoint 2010 product look
- Completing the upgrade: configure service applications, update database permissions, configure authentication, validate the upgrade, etc.
- Enjoy the SharePoint 2010 awesomeness.
To learn more about how to build a sound SharePoint environment, check out our Upcoming Courses
If you get an error "An unhandled exception occurred in the Silverlight Application in SharePoint 2010" when you try to create a document library, list, site or anything in SharePoint 2010 (using new fancy Silverlight control), then it could be that security validation has been disabled Webpart Security Validation under Web Application General Settings in SharePoint Central Administration. Apparently, Silverlight application is unable to connect to the WCF endpoint configured by the product for enabling Client Object Model, if Security validation is set to Off. Enable it, and you should be fine…
If you get the following error "TF249063: The following Web service is not available: http://SERVER:17012/_vti_bin/TeamFoundationIntegrationService.asmx. This Web service is used for the Team Foundation Server Extensions for SharePoint Products. The underlying error is: The remote server returned an error: (404) Not Found. Verify that the following URL points to a valid SharePoint Web application and that the application is available: http:// SERVER:17012. If the URL is correct and the Web application is operating normally, verify that a firewall is not blocking access to the Web application.", when you try to create new projects in TFS 2010 or simply when you browse to SharePoint Extensions tab in TFS Administration Console, then most likely its caused by the fact that Team Foundation Server Extensions for SharePoint Products (aka TFS 2010 Solutions in SharePoint 2010 or 2007) were not installed properly. To resolve this issue you need to add those solutions manually to the solutions store and then deploy them:
- Open Command Prompt
- Change your directory to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\\bin\ (for SharePoint 2010) and C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\\bin\ (for SharePoint 2007)
- Add TFS 2010 solutions using stsadm.exe command as follows:
stsadm -o addsolution -filename "C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Templates\Microsoft.TeamFoundation.SharePoint.wsp"
stsadm -o addsolution -filename "C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Templates\ TswaWebPartCollection.wsp"
stsadm -o addsolution -filename "C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Templates\Microsoft.TeamFoundation.SharePoint.Dashboards.wsp"
- Then deploy solutions using either SharePoint Central Administration site or stsadm.exe command as follows:
stsadm -o deploysolution -name Microsoft.TeamFoundation.SharePoint.wsp -local –force
stsadm -o deploysolution -name TswaWebPartCollection.wsp -local –force
stsadm -o deploysolution -name Microsoft.TeamFoundation.SharePoint.Dashboards.wsp –url "YOUR WEB APP URL" –force
- Go back to TFS Administration Console and Grant Access to your SharePoint farm
- Under SharePoint Web Applications tab, add SharePoint web application to be used for TFS-related SharePoint sites
- Under Team Project Collections, make sure that all your existing Project Collections are tied to your SharePoint instance.
That is all J
If you get "Load control template file /_controltemplates/TaxonomyPicker.ascx failed: Could not load type 'Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker' from assembly…" error in your event logs on SharePoint 2010 server, then it's most likely caused by "corrupted" code in TaxonomyPicker.ascx file. To fix the problem:
- Go to <drive>:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES
- Backup TaxonomyPicker.ascx before making any changes to it, then open TaxonomyPicker.ascx file to edit
- Find the following line: <%@ Control className="TaxonomyPickerControl" Language="C#" Inherits="Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker,Microsoft.SharePoint.Portal, Version=188.8.131.52, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
- Replace ',' with ',', so the line looks like this
<%@ Control className="TaxonomyPickerControl" Language="C#" Inherits="Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker,Microsoft.SharePoint.Portal, Version=184.108.40.206, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Control className="TaxonomyPickerControl" Language="C#" Inherits="Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker,Microsoft.SharePoint.Portal,Version=220.127.116.11, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
When you upload a large file (over 50Mb usually) to SharePoint 2010, you might get an "Error 0x800700DF: The file size exceeds the limit allowed and cannot be saved" message. Obviously, the first thing you need to check is to ask your SharePoint administrator what is your current file size upload quota. If the quota is not a problem, then the error is most likely caused by a local restriction set on Web Client service. By default, Web Client file size limit is set to 47Mb or so. To increase this limit:
- Open Windows Registry using regedit command
- Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
- Right click on the FileSizeLimitInBytes and click Modify
- Click on Decimal, and type 4294967295 and click OK
- Restart Web Client service using Services snapin.
This will increase the Web Client file size limit to 4Gb, which is a maximum file size you can upload using WebDAV. Please note, that this will only address Web Client service restrictions, and will not increase your SharePoint quota. Only your SharePoint Administrators can do that, so be nice to them J
If you need to run load tests (or any other tests) against your web application, the most efficient way to do it is to use "the cloud": Amazon Elastic Cloud or Windows Azure servers. Why? Two simple reasons:
- It's easy spin up as many servers as you need, which make it easier to scale up or down your test rig environment
- It's external to your environment, which is necessary to make your tests closer to a real life scenario
I won't bore you with details on how to set up your TFS environment and all. We're all adults; we know how to read install guides. I will only cover the things are not in any of those guides.
Server instance setup in Amazon EC2 (applicable to Windows Azure as well):
- Pick large instance type or better. Small instance just is not powerful enough.
- Use Windows Server 2008 operating system as host. Amazon EC2 does not support Windows Server 2008 R2 yet, and there is no good reason to still use Windows Server 2003 operating system.
- Use an instance with SQL Server 2008 Express pre-installed to save time, unless you think your databases will be larger than 4Gb (very unlikely scenario in this cases)
- When going through "Launch an instance" wizard, at the Security Groups screen, pick Default group and create new security group (you don't have to configure new security group now, this can be done later). Make sure both of those groups were selected as this will save you a lot of headache later.
- Assign public IPs to your "cloud" servers and make sure that ISP that hosts your web application does not block or quarantine those IPs.
Host OS setup:
- Disable Simple File Sharing. I am not sure why this feature is enabled on the servers.
- Add your service account(s). To keep these notes simple, we will stick with one service account: tfsservice. Make sure all of your server instances have the same user accounts added (with the same passwords, of course)
- If you're feeling lazy, grant your service account a local administrator's permissions
- Make sure all of your "cloud" servers can see one another. If not, tweak your security groups in AWS Management Console.
TFS 2010 server tweaks:
- Make sure that the user account with the same name and password as the service account on the cloud servers exists in the environment that hosts TFS 2010. Could be a local account on the TFS server or domain account.
- Make sure that this service account is a member of Project Collection Administrators group, Project Collection Service Accounts group, and Project Collection Test Service Accounts group. Use tfssecurity.exe to add your user to those groups, if GUI does not let you.
- In some cases, using SSL when connect to your TFS server does not work, so configure your TFS server to accept connections on HTTP port as well (for example, port 8080)
Test Controller configuration:
- Make sure that the account you're using to run Test Controller service is a member of TeamTestAgentService local group
- Always use ".\" instead of a domain name or machine name when provide credentials. For example, ".\tfsservice", instead of "SERVERNAME\tfsservice"
- Do not register your test controller with any TFS project collection just yet
- Enter SQL Server instance that will be hosting your Load Test database
- Add virtual user licenses
Test Agent configuration:
- Always use ".\" instead of a domain name or machine name when provide credentials. For example, ".\tfsservice", instead of "SERVERNAME\tfsservice"
- Enter the machine name of your test controller. Use port default port 6901, unless you have configured your test controller to listen on a different port
I hope you found this info useful. If you have any questions or comments, shoot me an email at max [at] objectsharp [dot] com.
Just wanted to share this funny looking error I got on a SharePoint 2010 server recently: http://twitpic.com/3guyk8
I have no idea how or why this happened, but after I have refreshed the page it was gone and I never got it back. No errors were posted in the logs either J
Recently I have run into the situation where I was performing some maintenance work on SharePoint (backups, applying patches, you know – that kind of stuff), but the existing database connections to SharePoint were preventing me from doing my work. The way around this was to kill the remaining database connections, and here is how this can be done:
- Open SQL Management Studio
- Go to Management, and right click on Activity Monitor. Click on View Processes to get the list of all database connections
- Sort by a connection to a specific SharePoint database.
- Right click on a connection and click Kill Process.
- Do the same for all database connections to SharePoint, and you can carry on with your SharePoint maintenance tasks
Well, I was looking through SharePoint web.config file one time and asked myself how SharePoint knows where to find its contents. I know, it's a weird question to ask, but what can I say… I am that kind of person. Anyways, obviously looking through web.config did not yield any results, so I looked googled it. By the way, I do not know why, but I keep calling searching online as "googling" even though I switched to Bing a while ago. Old habits die hard, I guess, but I digress… After a little of research, I have found this blog post that has explained how SharePoint 2010 or 2007 finds its content. Basically, this is how it works:
- User types in the URL of the SharePoint website
- IIS gets a HTTP request, then handles it based on port number or a host header specified in the request
- Matching SharePoint website hands all requests to ASP.NET (thanks to wild card ISAPI mappings), which does all kinds of magic with the request
- Then, SPRequest HTTP module (defined in the web.config) gets into the play. SPRequest module does its magic too, and eventually request the location of the SharePoint configuration database from the registry. Connection string for the SharePoint configuration database is set using DSN key at HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB (for SharePoint 2007) or HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\Secure\ConfigDB (for SharePoint 2010). So, this is the registry value, you need to change, if you ever need to move configuration database.
- SharePoint configuration database knows where everything about the SharePoint farm, so it is (relatively speaking) "no brainer" from that point on… and the user sees an awesome SharePoint page on the screen.
It's that easy J
Recently, I have been installing and configuring a lot of TFS 2010 environments. Really, a lot of TFS 2010 (production, test, proof-of-concept) servers. Occasionally, I anger TFS "gods", so TFS installer throws an error and complain that certain TFS components does not have enough memory complete the install. It turns out that SharePoint component of TFS environment requires minimum of 1Gb of memory to operate. So does, TFS Build server… Otherwise, you'll end with this error in the installer log: " TF255157: The amount of RAM available on this computer is not sufficient to complete this process. You must have the following amount of RAM available: 1024 MB…"
Usually adding more memory to the servers hosting TFS components solves the problem, but if you can't wait to start playing with awesome TFS 2010, here is how you can override TFS 2010 installer behaviour:
- Create new environmental variable called TFS_IGNORE_VMEMORY and set its value to 1
- Restart your Team Foundation Configuration Wizard (not the entire server), and this time TFS "gods" will like you again.
Please note, just because you bypassed memory constraints preconfigured in TFS 2010 installer, it does not mean that you should not add more memory to your servers. Your TFS 2010 servers will work so much better, when its server meet (or exceed) the memory requirements…