Install SharePoint 2013 on Windows Server 2012 R2

SharePoint server 2013 slipstreamed with SP1 is available via MSDN and VLSC, this supports Windows Server 2012 R2.       

http://blogs.technet.com/b/office_sustained_engineering/archive/2014/03/03/announcing-availability-of-slipstreamed-office-2013-and-sharepoint-server-2013-with-sp1.aspx

SharePoint Server 2013 SP 1 is released http://support.microsoft.com/kb/2817429, I havent personally tested this on Server 2012 R2 yet, but based on the KB article it is supported.

SharePoint 2013 is not supported on Windows Server 2012 R2, however according to MS SharePoint 2013 SP1 will be supported…

http://support.microsoft.com/kb/2891274.

However if you are a person who likes to work on bleeding edge and doesn’t want to wait till SP1 is release …then you are at the right place J.

For almost all of my SharePoint Installations (2010 and 2013) be it on a single server or a large farm of many servers, I use autospinstaller, an open source PowerShell script library for scripted SharePoint installs.

http://autospinstaller.codeplex.com/

However autospinstaller failed during the SP2013 prerequisites install on the R2 server with the following errors.

1. Error: Startup task doesn’t exist. This is not a continuation after a restart

2014-02-10 15:58:56 – C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\SharePointServerPreparationToolStartup_0FF1CE14-0000-0000-0000-000000000000.cmd
2014-02-10 15:58:56 – Error: Startup task doesn’t exist. This is not a continuation after a restart.
2014-02-10 15:58:56 – Locating the following command line arguments file:
2014-02-10 15:58:56 – E:\PrerequisiteInstaller.Arguments.txt

2. Error: [In HRESULT format] (-2147024894)

2013-10-02 15:59:02 – Created thread for installer
2013-10-02 15:59:02 – “C:\Windows\system32\ServerManagerCmd.exe” -inputpath “C:\Users\ADMINI~1\AppData\Local\Temp\PreB8C.tmp.XML”
2013-10-02 15:59:02 – Error: Unable to install (2)
2013-10-02 15:59:02 – Error: [In HRESULT format] (-2147024894)
2013-10-02 15:59:02 – Last return code (2)
2013-10-02 15:59:02 – Reading the following DWORD value/name…

Error: The tool was unable to install Application Server Role, Web Server (IIS) Role

SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired
2013-10-02 15:59:02 – Error: The tool was unable to install Application Server Role, Web Server (IIS) Role.
2013-10-02 15:59:02 – Last return code (2)
2013-10-02 15:59:02 – Options for further diagnostics: 1. Look up the return code value 2. Download the prerequisite manually and verify size downloaded by the prerequisite installer. 3. Install the prerequisite manually from the given location without any command line options.
2013-10-02 15:59:02 – Cannot retry

The SharePoint 2013 prerequisite installer checks the OS version and detects it as unsupported as well as the AppFabric install requires special configurations. Due to these issues I decided to install the prerequisites manually but use autospinstaller for SharePoint install. Below is the order in which I performed the tasks.

Prerequisites Install

  1. Login to your R2 server as Administrator. You can as well perform this step under the Farm Administrator account, which should be also local administrator on the server. Run the PowerShell as administrator and execute the following

a. Import-Module ServerManager

b. Add-WindowsFeature NET-WCF-HTTP-Activation45,NET-WCF-TCP-Activation45,NET-WCF-Pipe-Activation45 -Source E:\Sources\sxs

Add-WindowsFeature Net-Framework-Features,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering,Web-Digest-Auth,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,Application-Server,AS-Web-Support,AS-TCP-Port-Sharing,AS-WAS-Support, AS-HTTP-Activation,AS-TCP-Activation,AS-Named-Pipes,AS-Net-Framework,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-APIs,Web-Lgcy-Scripting,Windows-Identity-Foundation,Server-Media-Foundation,Xps-Viewer -Source E:\Sources\sxs

-Source parameter should point to the windows installation media.

2. Download all the below prerequisites and save it locally.

SQL Server 2008 R2 SP1 Native Client
Microsoft WCF Data Services 5.0
Microsoft Information Protection and Control Client (MSIPC)
Microsoft Sync Framework Runtime v1.0 SP1 (x64)
Windows Identity Extensions

Windows Identity Foundation (KB974405) – This may fail and not required, as WIF is turned on as part of step 1. Make sure it’s turned on as a Windows feature. (Added for completeness of prerequisites)
Windows Server AppFabric
CU 1 for AppFabric 1.1 (KB2671763)

3. Install all the above prerequisites directly from the prerequisites folder in the sequence ordered above, EXCEPT the last two (AppFabric and CU 1 for AppFabric).

4. AppFabric requires special configuration and installing it in a usual way is not enough for SP 2013 and Win Srv 2012 R2. Run the following command

WindowsServerAppFabricSetup_x64.exe /i CacheClient,CachingService,CacheAdmin /gac

5. Install AppFabric1.1-RTM-KB2671763-x64-EN2013-with-sp1.aspx

U

6. Restart your server

 SharePoint 2013 Install

In order to make use of all the benefits of a scripted install, I still wanted to use autspinstaller but didn’t want the prerequisites install on it to run. Therefore I modified the autospinstaller script to bypass prerequisite install. Below is the change I did to the script AutoSPInstallerMain.ps1.

Navigate to the function, “Function Run-Install” and comment the below so that prerequisites install is bypassed.

#InstallPrerequisites $xmlinput

Save the file and run the autospinstaller in a standard way, please note that you need to configure autospinstallerinput.xml file in a standard way. Refer http://autospinstaller.codeplex.com/

SharePoint 2013 Prerequisite install failed in Windows Server 2012 – Script error at “C:\Windows\system32\cscript.exe” “C:\Windows\system32\iisext.vbs” /enext “ASP.NET v4.0.30319

Couple of months back while provisioning a SharePoint 2013 farm at a client, I ended up hitting an error during the SharePoint Prerequisite install… wtf!!!

After some further investigation on the script’s error log, I manage to trace the root cause of the error and noticed that it occurred when enabling ASP.net v4.0.30319 during the “Web Server and IIS Role installation…”

The script failed at …“Failed at “C:\Windows\system32\cscript.exe” “C:\Windows\system32\iisext.vbs” /enext “ASP.NET v4.0.30319″

The reason is iisext.vbs (IIS Web Service Extension script) was missing in folder ‘C: \Windows\system32’

In order to get this working, add/enable “IIS 6 Scripting Tools” role service as part of the Web Server role installation via Server Manager -> Add Roles. (See the screenshot below)

IIS 6 Scripting Tool

Once the role installation is completed, SharePoint prerequisite install can commence.

Error when installing SQL Server 2012 on Windows Server 2012 – Error while enabling Windows feature: NetFx3, Error Code: -2146498298

When installing SQL Server 2012 on Window Server 2012, you will endup hitting this error if  .Net 3.5 (a windows feature) is not installed as a prerequisite.

“Error installing Microsoft .NET Framework 3.5….

Error while enabling Windows feature: NetFx3, Error Code: -2146498298, Please try enabling Windows feature: NetFx3 from Windows management tools and then run setup again…..”

To fix this, turn on feature ‘.Net Framework 3.5′ using “Turn Windows features on or off” option in Control Panel. This will open up a new wizard to “Add Roles and Features”, select .Net Framework 3.5 as shown below

Add.Net3.5Features

.Net framework 3.5 is not copied into the Server from the media during the install therefore we need to explicitly specify the ‘source path’ using ‘Specify an alternate source path’ as shown in the below screens.

FeaturesConfirmation

SourcePathChanges

Once the alternate source path is specified, click ‘Install’. After a successful install of .NET framework 3.5 you can commence the SQL Server 2012 install on the missing components.

Migrating from MOSS 2007 to SharePoint 2013

Technology needs upgrade and SharePoint is no exception infact newer versions of SharePoint are usually released in 3 year cycles. It is essential for businesses to upgrade to newer versions if they want to continuously leverage the new technological advancements in the IT industry.

When it comes to migrating SharePoint farms between different versions it has always been both interesting and challenging. The level of complexity in a SharePoint migration is proportional to the level of customiszations applied to the environment. All most all the SharePoint environments that I have worked on are customized to different levels of complexity, some are heavily customized with many complex custom workflows (SharePoint/.Net workflows, K2 and Nintex) and integrated with external systems via custom connectors or Business Connectivity Services (BCS), etc… These type of complex environments are often challenging to migrate and require proper planning and a phased approach.

In this article I will briefly talk about the some key aspects that are worth considering when migrating from MOSS 2007 to SharePoint 2013. I like to cover the migration from MOSS 2007 to SharePoint 2013 because this will include migration from SharePoint 2010 to SharePoint 2013 as well.

  1. Migrating Content has to be a 2 step process, if no 3rd party tools are used. I.e. Upgrade MOSS to a temporary 2010 environment via database attach and then move the content to SP2013 using the same approach. 3rd party tools such as AvePoint can also be utilized. Eventhough most of the content can be migrated ‘as is’, it’s important to use this opportunity to clean up the content before moving to SP2013.
  2. Migrating code, this has to be done manually and it’s a key component in the process of migration. The existing code needs to be analyzed and evaluated in detail before deciding on whether to build the solution from scratch or to do a code migration. You must look at code-based customizations, whether custom-built, in-house code, or third party tools, add-ins, or web parts, and determine what will and won’t work in the target version of SharePoint.
  3. The odds are pretty good that some of your customizations won’t work, and you will have to decide whether the functionality those customizations provide is still necessary, or whether the customization can be left behind. If the customization is necessary, but incompatible, you will have to determine the cost and effort required to remediate the customization so that it works with your target version. Most likely the core source code might be reusable so that you can avoid reinventing the wheel and thus reduce cost and effort.
  4. The effort that I have just mentioned is the same whether you are going to 2010 or 2013. And, in fact, it’s extremely likely that the remediation you undertake will result in the customization being ready for either version.
  5. It’s not the target version of SharePoint that is the issue rather it is the mess you have in your 2007 environment that is the real problem. Once you solve that, you are ready to migrate to either 2010 or 2013.
  6.  Permission and Authentication model, since SP2013 uses claims authentication by default and classic authentication is soon to be deprecated, special attention needs to be given to the new security model when architecting the whole solution. In my view point it’s better to do the permission migration separate to content and code migration, probably after the code and content migration which will help you to isolate and identify any specific permission related issues that may occur.

Some of the other general things that you might have to consider in successful migration and adaption of the new SP2013 are

  1. End user training and adoption
  2. Administrator training and familiarity of the system
  3. IT gets familiar with 2013 before making the decision.

If you move users from 2007 to 2010, that’s going to require training—a significant amount of training, in fact. SharePoint 2010 has rough edges in discoverability, and gaps in usability, that were solved in SharePoint 2013. That means that your users will require more training going from 2007 to 2010, than from 2007 to 2013. You’re also going to have to train users twice. You’ll have to train them to use 2010, and then when you do finally move to SharePoint 2013, you will have to train them again because the user interface and user experience is quite different in each version of SharePoint.

Taxonomy Field Values are not visible for Users other than Site Administrators

Background

Recently in one of the SharePoint 2010 implementations we faced the interesting issue of Taxonomy field values in Lists and Pages were not visible for users except Site Administrators.

 After spending sometime investigating I found out that in each site collection there is a hidden taxonomy list (TaxonomyHiddenList) which has all the taxonomy field values from the Manage Metadata Terms Database. This list will be synchronized hourly with the Manage Metadata database using the Taxonomy Update Scheduler  timer job.

 Reason

Users don’t have permission to access TaxonomyHiddenList

Solution

Give  ‘NT AUTHORITY\authenticated users’  read permission to the hidden list located at <sitecollection>/lists/TaxonomyHiddenList

Crawl issue with SharePoint 2010/FAST Search Server 2010

Backgroud:

During one of the recent FAST implementations, I faced another interesting issue with crawling internet sites and it is confirmed by Microsoft to be a product (SharePoint 2010) issue.  The details of my findings are given below.

Problem:

In SharePoint server 2010, you received following error when you try to crawl an anonymous + NTLM enabled web site (non-SharePoint site)

 “Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has “Full Read” permissions on the SharePoint Web Application being crawled.”

Cause:

It is confirmed to be  a product issue. 

Such issue can occur when you ever set a default content access account. In such scenario, Search will incorrectly pick up the default account and assume the site to crawl is NTLM and it fails to crawl the site using NTLM, it does not even fall back to anonymous.

Resolution:

MS Product Group has confirmed this to be product issue. However we were told, since changes required to fix the issue is big, they will more consider fixing it in future release of the product. 

Workarounds:

The below 2 workarounds are available to this issue, either of them will solve the issue

I.    Remove and re-provision a new search service application ( I know its a pain spcially if you have already set up hunderds of crawl rules/etc…). After the new search service application  is provisioned, DO NOT set or change the default content access account. (unfortunately, there is no public interface that can be used to take away the default content access account once it is there). Even retyping the password for the same default content access account will set the authentication type to NTLM as explained and will trigger the issue.

OR

II.    Create a crawl rule for the start address of the site and configure it to use cookie. 

  1. Create a dummy text file, i.e. dummy_cooki.txt, to contain some dummy text:   E.g. Test: testing
  2. Create a crawl rule to use cookie to crawl, and locate the cookie created in step 1 
  3. Specify whatever Error.aspx (it is more a dummy or filler, and is not really used)
  4.  Crawl again

 The idea is to configure SharePoint to crawl the site using cookie (from some degree, this can also be interpreted as anonymous). As long as the target site does not have the extra dummy cookie (many web sites don’t specifically look for cookies other than those sent by themselves), crawl can succeed.

Have a nice Day !!!

FAST Post Setup Configuration Failed

In one of my recent FAST implementations to a large Government Organization in Western Australia, I faced numerous interesting issues and would like to share them with the SharePoint communitiy in my next few articles.

In my view point, even though FAST is a very powerful and useful component when it comes to integration with SharePoint it need some major improvements, fixes and specially better error handling.

 

Issue 1: “Post Configuration of FAST failed”

Error/Exception in FAST install Logs:

Utility.WriteException – Exception –  : Exception – Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Utility.ExecutorException: Command returned non-zero         at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Utility.Executor.CheckReturnCode(Int32 returnCode)
at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Utility.Executor.ExecuteCommand(String command, String arguments, String workingDirectory, Int32 timeout, ILogWriter logWriter)

FAST farm Post Configuration failed with the above error message which is very generic and makes no sense, which forced us to reflect some dlls to find out the root cause of the issue.

The reason for the above error was the failure of  the command “d:\fastsearch\bin\msdtcsetup -admin”.

Again we dont have any clue of what prevents msdtcsetup from running therefore next we used NetMon (MS Network monitor tool) to analyse and further trouble shoot the network traffic. Netmon was very useful in finding out the exact root cause which was MSDC service permission was limited to Local Admin, LOCAL and INTERACTIVE by a group policy.

Since we found out the extract root cause the resolution was pretty simple, which is to add “Network Services” to the MSDC service permission group along with the other accounts and set the service to start up Automicatically.

As I mentioned earlier FAST needs better error handling…………..:(

 

Have a nice day !!!!

Read Issue 2: