As some of you noticed that in SharePoint 2013 welcome menu options “Sign in as Different User” is not available by default. You need this for various reasons and there is a work around to achieve it.
SP 2010 default Welcome Menu
SP 2013 default Welcome menu (missing “Sign in as Different User” option)
Go to the “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\CONTROLTEMPLATES”
Locate the following file welcome.ascx and open in Notepad.
Add the below code to the welcome.ascx as appear in image. In my case I have added at the start to appears as first option in welcome menu
<SharePoint:MenuItemTemplate runat="server" ID="ID_LoginAsDifferentUser" Text="<%$Resources:wss,personalactions_loginasdifferentuser%>" Description="<%$Resources:wss,personalactions_loginasdifferentuserdescription%>" MenuGroupId="100" Sequence="100" UseShortId="true" />
Navigate to the site and click on Welcome menu, the Sign in as Different User option is now available as appear below
Imagine you have created two SharePoint 2013 web applications. They are hosted on same web front end server with default post 80.The web applications URL’s are something like web1.eblogin.com and web2.eblogin.com. You want to enable SSL on both web applications and have wildcard SSL certificate (*.eblogin.com).
I came across this scenario during a project where I need to do SSL binding for Intranet site and my sites web applications. I have tried it with normal process. I opened the IIS 7 manager, clicked on the web1.eblogin.com web site and then under the actions menu “bindings” option, provided the binding details and clicked OK. I then repeated the same steps for web2.eblogin.com. As a result it eventually drops the SSL certificate binding for the web1.eblogin.com. I tried again on web1.eblogin.com which then drops the binding for web2.eblogin.com
Option 1: Always create SharePoint 2013 Web applications with SSL enabled and provide host header at the first place. It will do the SSL certificate binding automatically for the web application.
Option 2: The first workaround is not always applicable. For example, what if the business provide SSL certificate after you set up site structure or may be after site goes live. In this case you might end up re-creating the web applications with SSL enabled and reattach content database to them. So the resolution to this is
Go to front end web server where the web applications are hosted
Open command prompt
Navigate to the AppCmd.exe physical directory
Run the following command for each web application to do SSL binding
//command to run appcmd set site /site.name:" Site name as appear in IIS" /+bindings.[protocol='https',bindingInformation='*:443:web1.eblogin.com]
After this you can run the following Windows PowerShell command to get the binding details for a particular web application
Get-WebBinding ‘Site Name as appear in IIS '
I am in middle of testing a SharePoint 2010 to SharePoint 2013 project upgrade. I have faced couple of issues, the one is that the List “Quick edit” button is disabled in SharePoint 2013 after upgrade content database from SharePoint 2010
I have just created a datasheet view in SharePoint 2013 list, clear browser cache and render the list page again. I have switched the view to datasheet view and now I am able to do bulk editing. When switched back to main view I found that “Quick edit” button is now enabled under list tab.
You can also create “Access view” which will download the list schema with data into access database. You can make the changes in access and hit save. It will sync the changes to SharePoint list. You can also get the latest SharePoint 2013 list data by clicking “Refresh all.
The following steps will explain the upgrade process of SharePoint web application from SP 2010 to SP 2013 Farm
Backup the Content database from SP2010 server using SQL management studio
Move the database to SharePoint 2013 SQL server.
Restore the content database on SharePoint 2013 SQL server using SQL management studio
Upgrade custom code from visual studio 2010 to VS 2012 and Version 15 of SharePoint (Recommended). Although, you can still deploy the SharePoint 2010 code on SharePoint 2013 Farm under 14 hive)
Create new web application and root site collection in SharePoint 2013 Farm using “Central Administration”
Deploy custom solutions to the SharePoint 2013 Farm (make sure they are deployed on new web application)
Remove the default content database from the newly created web application using “Central Admin”
Attach the SharePoint 2010 web application content database to new web application in SP 2013 using PowerShell script
Run Test-SPContentDatabase cmdlet to identify missing components along with potential errors and related warnings. Check the upgrade log and deploy any missing components and re run the cmdlet to verify.
Test-SPContentDatabase -name WSS_Content_DB -webapplication http://sitename
Attach the content database to the SharePoint 2013 web application using Mount-SPContentDatabase cmdlet.
// Mount-SPContentDatabase "MyDatabase" -DatabaseServer "MyServer" -WebApplication http://sitename
Navigate to the site and run visual upgrade (To upgrade the site simply click on “Start now” link on the toolbar, you can also go to Site Upgrade page from Site Setting page as well).
Once the Upgrade complete, your site collection should now be accessible in SharePoint 15 mode
Note: The default authentication type in SharePoint 2013 is “Claim based”. You can still create web application with” Classic authentication” in SharePoint 2013 through PowerShell, but it is recommend using Claim based Authentication in SharePoint 2013 web apps for variety of reasons. Also, windows Classic mode authentication is deprecated in SharePoint 2013. If your SharePoint 2010 web application is set to classic mode authentication type, then change it to claim based authentication either before or after upgrade web App to SharePoint 2013 Farm.
For more info visit: http://technet.microsoft.com/en-us/library/gg251985.aspx
It is highly recommended to do bit cleaning before you do an upgrade of SharePoint 2010 environment to SharePoint 2013.We need to make sure that environment is running and fully functioning, and should clean up all those contents which doesn’t required upgrade.
You should consider the following items to clean up before upgrade.