While installing SharePoint 2013 prerequisites on Windows Server 2012 and SQL Server 2012, I have received the error "There was an error installing the prerequisites..." After checking out the logs (under %TEMP%\prerequisiteinstaller.<date>.<time>.log), you quickly learn that prerequisite install failed because of Microsoft SQL Server 2008 R2 SP1 Native Client. To bypass this problem, you can manually download Microsoft SQL Server 2008 R2 SP1 Native Client from http://download.microsoft.com/download/9/1/3/9138773A-505D-43E2-AC08-9A77E1E0490B/1033/x64/sqlncli.msi and install it. After you manually download Microsoft SQL Server 2008 R2 SP1 Native Client, go ahead and restart SharePoint 2013 prerequisite installer. Now SharePoint 2013 prerequisites should install successfully. J
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
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
Got an email the other day with a bunch of pictures to stick into my email signature, website, blog, slide decks, and etc for the SharePoint Summit in 2011 here in Toronto. Since I’m content with the size of my signature, have no access to modify this website’s layout, and will never remember to stick them into any of my slide decks, here they are
Please go visit the site, see if you are interested in any of the presentations, and if you are, go! It’ll be well worth the cost!
Yet another presentation on the docket! I submitted an abstract to SharePoint Summit 2011 and they accepted! I will be presenting on SharePoint and how it manages Identity. More specifically, how SharePoint 2010 uses WIF to handle Claims based authentication and Federation.
Here are the details
Event: SharePoint Summit 2011, January 31st 2011 – February 2nd, 2011
When: 11:30 a.m. - 12:45 p.m. February 1st, 2011
Where: Four Seasons Hotel, Toronto
Abstract: Managing identities within an organization is relatively easy. However, as business changes, we need to be able to adapt quickly. Identity is something that often gets overlooked in adaptation. In this session we will discuss the Windows Identity Foundation and how SharePoint uses it to adapt easily to change.
When SharePoint 2010 was developed, Microsoft took extra care to include support for
a claims-based identity model. There are quite a few benefits to doing it this
way, one of which is that it simplifies managing identities across organizational
structures. So lets take a look at adding a Secure Token Service as an Authentication
Provider to SharePoint 2010.
First, Some Prerequisites
You have to use PowerShell for most of this. You wouldn’t/shouldn’t be adding
too many Providers to SharePoint all that often so there isn’t a GUI for this.
The claims that SharePoint will know about must be known during setup. This
isn’t that big a deal, but…
Telling SharePoint about the STS
Once you’ve collected all the information you need, open up PowerShell as an Administrator
and add the SharePoint snap-in on the server.
Next we need to create the certificate and claim mapping objects:
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("d:\path\to\adfsCert.cer")
$claim1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
-IncomingClaimTypeDisplayName "Role" –SameAsIncoming
$claim2 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
-IncomingClaimTypeDisplayName "EmailAddress" –SameAsIncoming
There should be three lines. They will be word-wrapped.
The certificate is pretty straightforward. It is the public key of the STS.
The claims are also pretty straightforward. There are two claims: the roles
of the identity, and the email address of the identity. You can add as many
as the STS will support.
Next is to define the realm of the Relying Party; i.e. the SharePoint server.
$realm = "urn:" + $env:ComputerName + ":adfs"
By using a URN value you can mitigate future changes to addresses. This becomes
especially useful in an intranet/extranet scenario.
Then we define the sign-in URL for the STS. In this case, we are using ADFS:
$signinurl = https://[myAdfsServer.fullyqualified.domainname]/adfs/ls/
Mind the SSL.
And finally we put it all together:
New-SPTrustedIdentityTokenIssuer -Name "MyDomainADFS2" -Description "ADFS
2 Federated Server for MyDomain" -Realm $realm -ImportTrustCertificate $cert
-ClaimsMappings $claim1,$claim2 -SignInUrl $signinurl -IdentifierClaim $claim2.InputClaimType
This should be a single line, word wrapped. If you wanted to you could just
call New-SPTrustedIdentityTokenIssuer and then fill in the values one at
a time. This might be useful for debugging.
At this point SharePoint now knows about the STS but none of the sites are set up
to use it.
Authenticating SharePoint sites using the STS
For a good measure restart SharePoint/IIS. Go into SharePoint Administration
and create a new website and select Claims Based Authentication at the top:
Fill out the rest of the details and then when you get to Claims Authentication
Types select Trusted Identity Provider and then select your STS.
In this case it is my ADFS Server:
Save the site and you are done. Try navigating to the site and it should redirect
you to your STS. You can then manage users as you would normally with Active