It's official! Microsoft has released SP1 for Office 2013 and SharePoint 2013. More details can be found here: http://blogs.technet.com/b/office_sustained_engineering/archive/2014/02/25/announcing-the-release-of-service-pack-1-for-office-2013-and-sharepoint-2013.aspx
Enjoy!
Thursday, February 27, 2014
Wednesday, February 26, 2014
Collapsing Multiple SharePoint 2010 Web applications into a single SharePoint 2013 Web application using Host-Named Site Collections
At a client site, I was tasked to migrate a SharePoint 2010 farm from antiquated physical hardware to a new SharePoint 2013 farm in a virtual environment. In the existing SharePoint 2010 farm, there are several web applications separating different projects. This was done to isolate them from each other and provide more granular security. As we should all know by now, Microsoft's best practices within SharePoint 2013 is to use less web applications (limit of 20 web applications per farm) and implement host-named site collections to create multiple "zones" or to use unique URL headers. Side Note: If you want to learn more about Software boundaries and limits for SharePoint 2013 , visit: http://technet.microsoft.com/en-us/library/cc262787.aspx).
So began my effort to collapse multiple web applications from a SharePoint 2010 farm into a single web application in a new SharePoint 2013 farm.
Step 1: Identify possible duplicate URLs
The first step is to identify all of the sites within an existing web application to see if any of them have identical URL paths. For instance there may be a site "/sites/sitecollection1" and in both web applications. I like this little PowerShell cmdlt and use it quite frequently to see how our site collections are growing on a monthly/annual basis:
Get-SPWebApplication https://url.domain.com | Get-SPSite -Limit All | Get-SPWeb -Limit All | Select Title, URL, ID, ParentWebID | Export-CSV C:\filename.csv -NoTypeInformation
Step 2: Create Web Application
The next step is to create a new web application (if one doesn't already exist in the new farm). Depending on your authentication method, you can either use Central Administration (claims-based) or PowerShell (classic-mode). In our case, I needed to create the web application in classic mode and then convert it to claims after everything has been moved over. This was due to the fact that we were using Office Web Apps which requires claims-based authentication. Here is the cmdlet used to create the web application in classic-mode:
New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -AuthenticationMethod <WindowsAuthType> -ApplicationPoolAccount <ApplicationPoolAccount> -Port <Port> -URL <URL>
Side Note: For more information about classic-mode authentication, visit: http://technet.microsoft.com/en-us/library/gg276326.aspx
Step 3: Create Empty Root Site Collection
Next, we need to create the top-level site collection. This is a requirement for any new Web Application. Also, this will be the only site collection that shows up in the content source. Even though all other host-named site collections do not appear, by default search will automatically crawl them.
New-SPSite 'http://<servername>' -Name 'Portal' -Description 'Portal on root' -OwnerAlias 'domain\administrator' -language 1033 -Template 'STS#0'
New-SPSite 'http://portal.domain.com' -HostHeaderWebApplication 'http://<servername>’ -Name 'Portal' -Description 'Customer root' -OwnerAlias 'domain\administrator' -language 1033 -Template 'STS#0'
Step 5: Migrate existing SharePoint 2010 Content Databases to new Host-Named Site Collections
In the interest of staying on topic, I have skipped the steps that include attaching the content database(s), running the pre-upgrade check and testing the spcontent database. for more information on upgrading SharePoint 2010 databases to 2013, visit this site: http://technet.microsoft.com/en-us/library/cc303436.aspx
Restore-SPSite -Identity <SiteCollectionURL> -Path <Backup file> [-DatabaseServer <DatabaseServerName>] [-DatabaseName <ContentDatabaseName>] [-HostHeader <Host header>] [-Force] [-GradualDelete] [-Verbose]
Side Note from Author: Due to an unexpected time crunch, I decided to not collapse the web applications as part of the migration. I was hoping to be able to provide additional lessons learned and more information from actual experience, but unfortunately this is as far as I got in the production environment. Regardless, I wanted to document a few of these steps in case we decide to revisit this again in the future or on another contract.
So began my effort to collapse multiple web applications from a SharePoint 2010 farm into a single web application in a new SharePoint 2013 farm.
Step 1: Identify possible duplicate URLs
The first step is to identify all of the sites within an existing web application to see if any of them have identical URL paths. For instance there may be a site "/sites/sitecollection1" and in both web applications. I like this little PowerShell cmdlt and use it quite frequently to see how our site collections are growing on a monthly/annual basis:
Get-SPWebApplication https://url.domain.com | Get-SPSite -Limit All | Get-SPWeb -Limit All | Select Title, URL, ID, ParentWebID | Export-CSV C:\filename.csv -NoTypeInformation
Step 2: Create Web Application
The next step is to create a new web application (if one doesn't already exist in the new farm). Depending on your authentication method, you can either use Central Administration (claims-based) or PowerShell (classic-mode). In our case, I needed to create the web application in classic mode and then convert it to claims after everything has been moved over. This was due to the fact that we were using Office Web Apps which requires claims-based authentication. Here is the cmdlet used to create the web application in classic-mode:
New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -AuthenticationMethod <WindowsAuthType> -ApplicationPoolAccount <ApplicationPoolAccount> -Port <Port> -URL <URL>
Side Note: For more information about classic-mode authentication, visit: http://technet.microsoft.com/en-us/library/gg276326.aspx
Step 3: Create Empty Root Site Collection
Next, we need to create the top-level site collection. This is a requirement for any new Web Application. Also, this will be the only site collection that shows up in the content source. Even though all other host-named site collections do not appear, by default search will automatically crawl them.
New-SPSite 'http://<servername>' -Name 'Portal' -Description 'Portal on root' -OwnerAlias 'domain\administrator' -language 1033 -Template 'STS#0'
Step 4: Create Host-Named Site Collections
You must use PowerShell to create a host-named site collection, although you can manage it with Central Administration after it has been created.
New-SPSite 'http://portal.domain.com' -HostHeaderWebApplication 'http://<servername>’ -Name 'Portal' -Description 'Customer root' -OwnerAlias 'domain\administrator' -language 1033 -Template 'STS#0'
Step 5: Migrate existing SharePoint 2010 Content Databases to new Host-Named Site Collections
In the interest of staying on topic, I have skipped the steps that include attaching the content database(s), running the pre-upgrade check and testing the spcontent database. for more information on upgrading SharePoint 2010 databases to 2013, visit this site: http://technet.microsoft.com/en-us/library/cc303436.aspx
Restore-SPSite -Identity <SiteCollectionURL> -Path <Backup file> [-DatabaseServer <DatabaseServerName>] [-DatabaseName <ContentDatabaseName>] [-HostHeader <Host header>] [-Force] [-GradualDelete] [-Verbose]
Side Note from Author: Due to an unexpected time crunch, I decided to not collapse the web applications as part of the migration. I was hoping to be able to provide additional lessons learned and more information from actual experience, but unfortunately this is as far as I got in the production environment. Regardless, I wanted to document a few of these steps in case we decide to revisit this again in the future or on another contract.
Wednesday, February 5, 2014
Avoiding The Pitfalls of Installing and Configuring a SharePoint 2013 farm on Windows Server 2012 R2 - Part 1
Avoiding The Pitfalls of Installing and Configuring a SharePoint 2013 farm on Windows Server 2012 R2 - Part 1
There are several sources online that can assist with a new SharePoint installation, however until SP1 is released, Microsoft is not supporting installation on Windows Server 2012 R2. I have captured my lessons learned through an actual production installation that will hopefully prevent many of you the frustrations and headaches I've experienced throughout this process. I have focused more on the initial setup errors because getting over this hurdle is 90% of the effort. After this, everything is just a straight forward installation and tailored configuration to your environment that I'll put into PART TWO of this blog.I will assume you already have Windows 2012 R2 installed and a functioning Active Directory structure. I will not go into planning or architecture, but we'll agree that this installation/configuration will be done for a multi-tier (3) farm. I will also not address installing/configuring SQL Server in this blog (see my other blog post titled: Installing SQL Server for SharePoint 2013 - coming soon)
STEP ONE - Setting up Initial Service Accounts
The following service accounts are (at a minimum) needed for installing SharePoint bits:
Setup & Install Account
- This account must be a domain account and is used to install and configure SharePoint
- This account must be member of Local Administrators Group on the server
- This account must be assigned “dbcreator” and “securityadmin” server roles on SQL Server
Farm Account
- This account must be a domain account and is used to access databases and administering
- All the permissions required for this account will be automatically granted after completing SharePoint Farm SharePoint Farm Configuration Wizard
In the next part of this blog, I will address additional service accounts that will be needed for further configuration and customization of SharePoint 2013.
STEP TWO - Adding Server Roles & Features
If you have an Internet connection, use these cmdlets to add the necessary server roles and features for front-end web servers and application servers in the farm.
(estimated time: 30-45 minutes per server)
Import-Module ServerManager
Add-WindowsFeature NET-WCF-HTTP-Activation45,NET-WCF-TCP-Activation45,NET-WCF-Pipe-Activation45
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 d:\sources\sxs
The reason I recommend using PowerShell in this instance is because when you use the PrerequisiteInstaller.exe, it will execute this Windows PowerShell code to install the Roles and Features to configure Windows Server 2012 for SharePoint 2013. Part of the Windows PowerShell code for Add-WindowsFeature installation installs the Windows NET-Framework-Core feature that is the Microsoft .NET Framework 3.5. This feature installation requires binaries and other files that are not included in a default installation of Windows Server 2012. because of this, you may get an error using the GUI and will need to point to the installation source files Windows 2012 R2.
Note:
If the server does not have an Internet connection, the PrerequisiteInstaller.exe cannot continue past the "Configuring Application Server Role, Web Server (IIS Role)" phase, and you may receive the following error message:
Normally just running the PrerequisitesInstaller.exe will work, however in our environment, we had the servers configured to use WSUS instead of Windows Update, so I was getting the following error:SharePoint 2013 Pre requisites install fail, Error: The tool was unable to install Application Server Role, Web Server (IIS) Role. This is more or less the same error you will receive in the previous section, except for a different (but same) reason.
1. Download all prerequisites from the Internet and save it on local disk of the server, e.g. C:\SP2013Prereqs
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 Server AppFabric
CU 1 for AppFabric 1.1 (KB2671763)
2. Install all prerequisites directly from the prerequisites folder in the download sequence, EXCEPT AppFabric and CU 1 for AppFabric.
3. AppFabric requires special configuration using following statement from command line:WindowsServerAppFabricSetup_x64.exe /i CacheClient","CachingService","CacheAdmin /gac
4. Install AppFabric1.1-RTM-KB2671763-x64-ENU
5. Restart your server
Online method (as described in http://support.microsoft.com/kb/2765260):
Open an elevated Windows PowerShell prompt on the SharePoint server (that is, Run as Administrator), and execute the following commands:
Import-Module ServerManager
Add-WindowsFeature NET-WCF-HTTP-Activation45,NET-WCF-TCP-Activation45,NET-WCF-Pipe-Activation45
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 d:\sources\sxs
The reason I recommend using PowerShell in this instance is because when you use the PrerequisiteInstaller.exe, it will execute this Windows PowerShell code to install the Roles and Features to configure Windows Server 2012 for SharePoint 2013. Part of the Windows PowerShell code for Add-WindowsFeature installation installs the Windows NET-Framework-Core feature that is the Microsoft .NET Framework 3.5. This feature installation requires binaries and other files that are not included in a default installation of Windows Server 2012. because of this, you may get an error using the GUI and will need to point to the installation source files Windows 2012 R2.
Note:
If the server does not have an Internet connection, the PrerequisiteInstaller.exe cannot continue past the "Configuring Application Server Role, Web Server (IIS Role)" phase, and you may receive the following error message:
The 0x800F0906 error code indicates that the computer cannot download the required files from Windows Update. In Windows Server 2012 and Windows 8, the .NET Framework 3.5 is a Feature on Demand. The metadata for Features on Demand are included in Windows Server 2012 and in Windows 8. However, the binaries and other files that are associated with the feature are not included. When you enable this feature, Windows tries to contact Windows Update to download the missing information to install the feature. The network configuration and how computers are configured to install updates in the environment can affect this process. Therefore, you may encounter errors when you first install such features.
For more information about error codes that may occur when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012, see the following Microsoft Knowledge Base article:
2734782 Error codes when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012
For more information about error codes that may occur when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012, see the following Microsoft Knowledge Base article:
2734782 Error codes when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012
STEP THREE - Install the Prerequisites
Normally just running the PrerequisitesInstaller.exe will work, however in our environment, we had the servers configured to use WSUS instead of Windows Update, so I was getting the following error:SharePoint 2013 Pre requisites install fail, Error: The tool was unable to install Application Server Role, Web Server (IIS) Role. This is more or less the same error you will receive in the previous section, except for a different (but same) reason.
If you come across this issue, there are 2 ways to solve the issue. If it's an issue with connecting to Windows Update, you may need to set the following Local Policy:
1. Windows Start
2. Run MMC
2. Run MMC
3. Click File, Add/Remove Snap-in…
4. Select Group Policy Object Editor and ADD it
5. Navigate to Administrative templates / System
6. Select and edit “Specify Settings for optional component installation and component repair”
Enable and select “Contact Windows Update directly to download repair content instead of Windows Server Update Services (WSUS)”
Enable and select “Contact Windows Update directly to download repair content instead of Windows Server Update Services (WSUS)”
7. Re run the prerequisite installation
If this still doesnt work, your only other option is to manually install the prerequisites:
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 Server AppFabric
CU 1 for AppFabric 1.1 (KB2671763)
2. Install all prerequisites directly from the prerequisites folder in the download sequence, EXCEPT AppFabric and CU 1 for AppFabric.
3. AppFabric requires special configuration using following statement from command line:WindowsServerAppFabricSetup_x64.exe /i CacheClient","CachingService","CacheAdmin /gac
4. Install AppFabric1.1-RTM-KB2671763-x64-ENU
5. Restart your server
At this point, you should be able to install the SharePoint Server 2013 bits on all web-front ends and application servers without any errors.
(see my next blog post titled: Avoiding The Pitfalls of Installing and Configuring a SharePoint 2013 farm on Windows Server 2012 R2 - Part 2 - coming soon)
(see my next blog post titled: Avoiding The Pitfalls of Installing and Configuring a SharePoint 2013 farm on Windows Server 2012 R2 - Part 2 - coming soon)
Subscribe to:
Posts (Atom)