SharePoint 2013: Excel web access web part errors

If you have recently migrated from SharePoint 2010 to SharePoint 2013 or if you are configuring excel web access web part for SharePoint 2013 with named component, you might notice that you Excel web access web parts are showing some error or not showing any data even after you add your excel file location to Trusted locations in excel service application.

There are multiple reasons behind this behavior of excel web access web part.

1. If you are getting error "Workbook cannot be opened" as shown in below image, It is related to permissions to the service account used for Excel services. As all your excel files are stored in Content DB, service account used for Excel service should be having access to all respective web applications.

You can use following cmdlets to get this issue resolved:

$webApplication = Get-SPWebApplication –Identity <URL of the Web application>

$webApplication.GrantAccessToProcessIdentity("<insert service account>")

You have to perform this action for all your web applications using excel web access web parts

2. You see the error "We're sorry, we couldn't open your workbook. It is possibly corrupt or using a file format that's not supported. Do you want to try and open this file in excel?" as shown in below image.

This error is very miss leading at times. There are chances that your excel file is corrupt but you better be sure about this.

To verify

1. Download the file to local system and open it in excel. If it does not open correctly then you can say it is  corrupt and need to be changed.
2.  If it opens correctly then nothing is wrong with file, you have to check for other resolution. In this case it might be the fact that you have not started Excel web service on all your web front end servers. 

Once you start the excel web service on all your web front end servers. This issue will be gone.

3. After getting rid off above issues, you notice nothing is coming up in excel web part not even error. It is showing sort of blank. This could happen to the web part if you are running RTM build for SharePoint 2013. If you have configured the excel web access web part with "Named component" you will get this error in SharePoint 2013 RTM. This is a known issue and is resolved in March 2013 PU for SharePoint 2013.

You can find original post on THIS location.

Language packs in SharePoint Server 2013

Site owners or site collection administrators who create sites or site collections can select a language for each site or site collection.

The language that they select has a language identifier (ID). The language ID determines the language that is used to display and interpret text that is on the site or site collection. For example, when a site owner creates a site in French, the site's toolbars, navigation bars, lists, and column headings appear in French. Similarly, if a site owner creates a site in Arabic, the site's toolbars, navigation bars, lists, and column headings appear in Arabic. In addition, the default left-to-right orientation of the site changes to a right-to-left orientation to correctly display Arabic text. 

The language packs that are installed on the web and application servers determine the list of available languages that you can use to create a site or site collection. By default, sites and site collections are created in the language in which SharePoint 2013 was installed. For example, if you install the Spanish version of SharePoint 2013, the default language for sites, site collections, and web pages is Spanish. If someone has to create sites, site collections, or web pages in a language other than the default SharePoint 2013 language, you must install the language pack for that language on the web and application servers. For example, if you are running the French version of SharePoint 2013, and a site owner wants to create sites in French, English, and Spanish, you must install the English and Spanish language packs on the web and application servers.

By default, when a site owner creates a new web page in a site, the site displays text in the language that is specified by the language ID.

Language packs are not bundled into multilingual installation packages. You must install a specific language pack for each language that you want to support. Also, language packs must be installed on each web and application server to make sure that that each web and application server can display content in the specified language.

Important:
You cannot change an existing site, site collection, or web page from one language to another by applying different language-specific site templates. After you use a language-specific site template for a site or a site collection, the site or site collection always displays content in the language of the original site template.  

Although a site owner specifies a language ID for a site, some user interface elements such as error messages, notifications, and dialog boxes do not display in the language that was specified. This is because SharePoint 2013 relies on several supporting technologies — for example, the Microsoft .NET Framework, Microsoft Windows Workflow Foundation, Microsoft ASP.NET, and SQL Server — some of which are localized into only a limited number of languages. If a user interface element is generated by any of the supporting technologies that are not localized into the language that the site owner specified for the site, the user interface element appears in English. For example, if a site owner creates a site in Hebrew, and the .NET Framework component displays a notification message, the notification message will not display in Hebrew because the .NET Framework is not localized into Hebrew. This situation can occur when sites are created in any language except the following: Chinese, French, German, Italian, Japanese, Korean, and Spanish.

Each language pack that you install creates a folder at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LAYOUTS\Locale_ID that contains language-specific data. In each locale_ID folder, you must have only one HTML error file that contains the error information that is used when a file cannot be found. Anytime a file cannot be found for any site in that language, this file will be used. You can specify the file to use by setting the FileNotFoundPage for each web application.

In some cases, some text might originate from the original installation language, which can create a mixed-language experience. This kind of mixed-language experience is typically seen only by content creators or site owners and is not seen by site users.



Downloading language packs

Follow these steps for each language that you want to support. If you decide to download more than one language, please be aware that a unique file that has a common name is downloaded for each language. Therefore, make sure that you download each language pack to a separate folder on the hard disk so that you do not overwrite a language pack of a different language.

Important:
By default, the Windows PowerShell Help files are installed in English (en-us). To view these files in the same language as the operating system, install the language pack for the same language in which the operating system was installed.  


Installing language packs on the web and application servers

After you install the necessary language files on the web and application servers, you can install the language packs. Language packs are available as individual downloads (one download for each supported language). If you have a server farm environment and you are installing language packs to support multiple languages, you must install the language packs on each web and application server. 

Important
The language pack is installed in its native language. The procedure that follows is for the English language pack.


To install a language pack  

1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
2. In the folder where you downloaded the language pack, run setup.exe.
3. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.
4. The Setup wizard runs and installs the language pack.
5. Rerun the SharePoint Products Configuration Wizard by using the default settings. If you do not run the SharePoint Products Configuration Wizard after you install a language pack, the language pack will not be installed correctly.

The SharePoint Products Configuration Wizard runs in the language of the base installation of SharePoint 2013, not in the language of the language pack that you just installed.


To rerun the SharePoint 2013 Configuration Wizard  

1. Verify that the user account that is performing this procedure is the Setup user account. For information about the Setup user account, see Initial deployment administrative and service accounts in SharePoint 2013.
2. Click Start, point to All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Products Configuration Wizard.
3. On the Welcome to SharePoint Products page, click Next.
4. Click Yes in the dialog box that alerts you that some services might have to be restarted during configuration.
5. On the Modify Server Farm Settings page, click Do not disconnect from this server farm, and then click Next.
6. If the Modify SharePoint Central Administration Web Administration Settings page appears, do not change any of the default settings, and then click Next.
7. After you complete the Completing the SharePoint Products and Technologies Configuration Wizard, click Next.
8. On the Configuration Successful page, click Finish.
9. After you install a new language pack and rerun the Rerun the SharePoint 2013 Configuration Wizard, you must deactivate and then reactivate any language-specific features before you use the new language pack.

When you install language packs, the language-specific site templates are installed in the %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\TEMPLATE\LanguageID directory, where LanguageID is the Language ID number for the language that you are installing. 
For example, the United States English language pack installs to the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\15\TEMPLATE\1033 directory. 
After you install a language pack, site owners and site collection administrators can create sites and site collections based on the language-specific site templates by specifying a language when they are creating a new SharePoint site or site collection.



Uninstalling language packs

If you no longer have to support a language for which you have installed a language pack, you can remove the language pack by using the Control Panel. Removing a language pack removes the language-specific site templates from the computer. All sites that were created that have those language-specific site templates will no longer work (It could cause many issues that is, the URL will produce a HTTP 500 - Internal server error page, broken layout, mixture of default, and uninstalled language.). Reinstalling the language pack will make the site functional again.

You cannot remove the language pack for the version of SharePoint 2013 that you have installed on the server. For example, if you are running the Japanese version of SharePoint 2013, you cannot uninstall the Japanese language support for SharePoint 2013.


Available language packs for SharePoint 2013

Language	Language ID	SharePoint Foundation 2013	SharePoint Server 2013	SharePoint Online
Arabic	1025	Yes	Yes	Yes
Azeri (Latin)	1068	Yes	Yes	No
Basque (Basque)	1069	Yes	Yes	Yes
Bosnian (Latin)	5146	Yes	Yes	No
Bulgarian	1026	Yes	Yes	Yes
Catalan	1027	Yes	Yes	Yes
Chinese (Simplified)	2052	Yes	Yes	Yes
Chinese (Traditional)	1028	Yes	Yes	Yes
Croatian	1050	Yes	Yes	Yes
Czech	1029	Yes	Yes	Yes
Danish	1030	Yes	Yes	Yes
Dari	1164	Yes	Yes	No
Dutch	1043	Yes	Yes	Yes
English	1033	Yes	Yes	Yes
Estonian	1061	Yes	Yes	Yes
Finnish	1035	Yes	Yes	Yes
French	1036	Yes	Yes	Yes
Galician	1110	Yes	Yes	Yes
German	1031	Yes	Yes	Yes
Greek	1032	Yes	Yes	Yes
Hebrew	1037	Yes	Yes	Yes
Hindi	1081	Yes	Yes	Yes
Hungarian	1038	Yes	Yes	Yes
Indonesian	1057	Yes	Yes	Yes
Irish	2108	Yes	Yes	No
Italian	1040	Yes	Yes	Yes
Japanese	1041	Yes	Yes	Yes
Kazakh	1087	Yes	Yes	Yes
Korean	1042	Yes	Yes	Yes
Latvian	1062	Yes	Yes	Yes
Lithuanian	1063	Yes	Yes	Yes
Macedonian	1071	Yes	Yes	No
Malay (Malaysia)	1086	Yes	Yes	Yes
Norwegian (Bokmål)	1044	Yes	Yes	Yes
Polish	1045	Yes	Yes	Yes
Portuguese (Brazil)	1046	Yes	Yes	Yes
Portuguese (Portugal)	2070	Yes	Yes	Yes
Romanian	1048	Yes	Yes	Yes
Russian	1049	Yes	Yes	Yes
Serbian (Cyrillic)	3098	Yes	Yes	Yes
Serbian (Latin)	2074	Yes	Yes	Yes
Slovak	1051	Yes	Yes	Yes
Slovenian	1060	Yes	Yes	Yes
Spanish	3082	Yes	Yes	Yes
Swedish	1053	Yes	Yes	Yes
Thai	1054	Yes	Yes	Yes
Turkish	1055	Yes	Yes	Yes
Ukrainian	1058	Yes	Yes	Yes
Vietnamese	1066	Yes	Yes	Yes
Welsh	1106	Yes	Yes	No

You can find original article on THIS link.

Service accounts strategy in SharePoint implementation

I often come across the SharePoint Farms that are installed and configured with a single service account (e.g. SPFarm account) . One service account to install the farm, to configure farm, to install service application and service application pools , and so on...
There is no precise way to determine how much service account you need on your farm but ONE is definitely too little and too wrong configuration in so many ways. Also one account is very unsafe configuration which can lead to complications down the road.

 Now that we've cleared that up let's determine which service accounts we usually need.

NOTE: This is the minimum number of service accounts that we need in order to properly install SharePoint. 

SQL_Admin is main SQL service account. This account needs to be a Local Administrator on the SQL server in order to be able to install SQL. With this account we will grant rights to SP_Farm service account.

SP_Farm is main SharePoint account. It needs to have Local Administrator rights to be able to install SharePoint Server and also the SecurityAdmin and DBcreator roles on the SQL Server to create the configuration and other databases. This account will be main Farm Administrator and also run the Timer Service and the web application for Central Administration use to access the SharePoint content database

SP_AppPool  is a domain account used for application pool identity. When you create a Web Application, and you create a pool for it, you select this account.

SP_ServiceApps is a domain account used for the Service Applications Pools. When you create a Managed Metadata Service application and create a pool for it, you select this account!

SP_Crawl is used within the Search Service Application to crawl content. The Search Service Application will automatically grant this account read access on all Web Applications. It will also run the SharePoint Windows Search Service.

SP_UserProfiles is the account used for the User Profile Synchronization between your Service Application and your Active Directory. This account does not need any local rights, however you need to give it Replicate Directory Changes rights on the Active Directory in order to allow the synchronization


Most commonly used Service Accounts are:

SQL_Admin is main SQL service account. This account needs to be a Local Administrator on the SQL server in order to be able to install SQL. With this account we will grant rights to SP_Farm service account.

SQL_Services is only used to run the SQL Agent and Database Engine windows services. This account does not have any local rights.

SP_Farm is a domain account that the SharePoint Timer service and the web application for Central Administration use to access the SharePoint content database. This account does not need to be a local administrator. The SharePoint configuration wizard grants the proper minimal privilege in the back-end SQL Server database.The minimum SQL Server privilege configuration is membership in the roles securityadmin and dbcreator.

SP_admin is a domain account you use to install and configure the farm. It is the account used to run the SharePoint Configuration Wizard  for SharePoint 2013. The SPAdmin account is the only account that requires local Administrator rights. 

SP_AppPool  is a domain account used for application pool identity. When you create a Web Application, and you create a pool for it, you select this account.

SP_ServiceApps is a domain account used for the Service Applications Pools. When you create a Managed Metadata Service application and create a pool for it, you select this account!

SP_Crawl is used within the Search Service Application  to crawl content. The Search Service Application will automatically grant this account read access on all Web Applications.

SP_Search Is used to run the SharePoint Windows Search Service.

SP_UserProfiles is the account used for the User Profile Synchronization between your Service Application and your Active Directory. This account does not need any local rights, however you need to give it Replicate Directory Changes rights on the Active Directory in order to allow the synchronization


This is most secure configuration but it is using most Service Accounts. 

SQL_Admin is main SQL service account. This account needs to be a Local Administrator on the SQL server in order to be able to install SQL. With this account we will grant rights to SP_Farm service account.

SQL_Services is only used to run the SQL Agent windows services. This account does not have any local rights.

SQL_Engine is only used to run the Database Engine windows service. This account does not have any local rights.

SP_Farm is a domain account that the SharePoint Timer service and the web application for Central Administration use to access the SharePoint content database. This account does not need to be a local administrator. The SharePoint configuration wizard grants the proper minimal privilege in the back-end SQL Server database.The minimum SQL Server privilege configuration is membership in the roles securityadmin and dbcreator.

SP_admin is a domain account you use to install and configure the farm. It is the account used to run the SharePoint Configuration Wizard  for SharePoint 2013. The SPAdmin account is the only account that requires local Administrator rights. 

SP_AppPool  is a domain account used for application pool identity. When you create a Web Application, and you create a pool for it, you select this account.

SP_ServiceApps is a domain account used for the Service Applications Pools. When you create a Managed Metadata Service application and create a pool for it, you select this account!

SP_Crawl is used within the Search Service Application  to crawl content. The Search Service Application will automatically grant this account read access on all Web Applications.

SP_Search Is used to run the SharePoint Windows Search Service.

SP_MySitePool  is a domain account used for the My Sites Web Application Pool Identity. It’s very similar to the SP_Pool, however it is only used for the My Sites Web Application.

SP_UserProfiles is the account used for the User Profile Synchronization between your Service Application and your Active Directory. This account does not need any local rights, however you need to give it Replicate Directory Changes rights on the Active Directory in order to allow the synchronization

This is not all Service accounts that we could use. Project server uses another 8 service account and so on, but I will write about that in another post .

You can find original post on THIS link.