Friday, March 27, 2015

Verifying the Excel Services Configuration for PowerPivot in SharePoint 2013

Verifying the Excel Services Configuration for PowerPivot in SharePoint 2013

In SharePoint 2013, Excel Services natively supports core PowerPivot functionality. This is an important improvement over previous releases. Without requiring an extra installation of PowerPivot components in the farm, users can interact with workbook data models in the browser. You only need to register a SQL Server Analysis Services (SSAS) server in the Excel Services configuration, as in the following screenshot, so that Excel Services can load and query the data models.
The specified SSAS server can reside anywhere in the local TCP/IP network but must exist in the same Active Directory forest as the SharePoint farm. The Excel Services service account must be granted server administrator permissions in the Analysis Services configuration. Furthermore, for SharePoint 2013 Preview, the specified server must run SQL Server 2012 SP1 CTP3 Analysis Services and the server must operate in SharePoint deployment mode. Note that SQL Server 2012 RTM Analysis Services and previous versions are not sufficient because these versions don’t support the new level of integration between Excel Services and Analysis Services.
When you register a SSAS server in Excel Services, it might take two or three minutes for the configuration changes to take effect. Of course, you can make the system apply the changes immediately by restarting Internet Information Services (IIS) using IISReset /NoForce or by restarting the Excel Services application in SharePoint Central Administration. I prefer IISReset because it’s uncomplicated. But what if Excel Services continues to tell you that data models cannot be loaded, as in the next screenshot? By following a few basic steps, you can quickly examine the Excel Services configuration and identify possible root causes.
Note   In order to verify that Excel Services can load a workbook data model, upload and open a sample workbook in the browser, and then click on a slicer. Excel Services typically shows cached data without loading the data model when opening a workbook. Clicking on a slicer requires Excel Services to update the data cache, which in turn requires actually loading the data model.
As always in SharePoint, start troubleshooting by checking the ULS logs. You can use UlsViewer, which is a handy tool available athttp://code.msdn.microsoft.com/ULSViewer, or use the Get-SPLogEvent cmdlet in the SharePoint Management Shell, or simply open the ULS log files in Notepad. If you use the Get-SPLogEvent cmdlet, start the Management Shell as Administrator and then set a filter for events from “Excel Services Application”, Category “Data Model”, and perhaps specify other criteria as well, such as the verbosity level, to narrow down the list of events that you must investigate. For example, I used the command Get-SPLogEvent | ?{$_.Area -eq "Excel Services Application" -And $_.Category -eq "Data Model" -And $_.Level -eq "Monitorable" } | Format-List to produce the output illustrated in the following screenshot.
The message in my example contains the error hint “Can't operate on empty server pool.” which means that Excel Services doesn’t have a server to load the data model. The solution is straightforward. Just register a SSAS server in the Data Model Settings of Excel Services and the server pool is no longer empty. Make sure you specify the SSAS server name correctly. Don’t forget to include the instance name, which is typically called POWERPIVOT. So, a server named AS2012SP1 running Analysis Services in SharePoint deployment mode would be specified as AS2012SP1\POWERPIVOT.
Note   As a best practice, do not use the label “localhost” or “.” in the SSAS server name. These labels refer to the local computer, which means that each Excel Services instance in a multi-machine farm would interpret the SSAS server name differently. Always specify the actual server name.
If you happen to mistype the server name, Excel Services writes a different error message to the ULS log, shown in the next screenshot. The message would state “There are no servers available or actively being initialized” which means that Excel Services knows about a SSAS server, but this server can currently not be located. The command Get-SPLogEvent | ?{$_.Area -eq "Excel Services Application" -And $_.Category -eq "Data Model" } | Format-List would include this ULS log entry in its results.
It is important to point out that a mistyped server name is only one of many possible causes of this error message. The server name isn’t necessarily incorrect. The server might just be down or rebooting for some reason. This could be a temporary situation that doesn’t require any configuration adjustments. Of course, it could also be a more permanent issue on the SSAS server, such as an incorrectly configured firewall blocking incoming connections. See if the ULS log contains additional hints. In the following screenshot, the error message states that the SQL Browser service is inaccessible. Opening the firewall solves this problem. For details about firewall configurations for Analysis Services, check out the article “Configure the Windows Firewall to Allow Analysis Services Access” athttp://msdn.microsoft.com/en-us/library/ms174937.aspx.
Having fixed the firewall configuration, the next common source of problems revolves around the service account permissions in Analysis Services. As mentioned, the Excel Services service account must be granted Analysis Services administrator permissions. If this is not the case, you can find the following error message in the ULS Log.
The message “Check Administrator Access (AS2012SP1\POWERPIVOT): Fail.” means that the Excel Services service account does not have the required permissions on the Analysis Services instance AS2012SP1\POWERPIVOT. If you grant the permissions in SQL Server Management Studio (SSMS), the administrator access check will pass, as hopefully will do all the other Analysis Services server checks that Excel Services performs at regular intervals. Here’s a successful sequence of all the server checks taken from the ULS log on a properly configured and functioning SharePoint 2013 application server:
  1. Checking Server Configuration (AS2012SP1\POWERPIVOT) ...
  2. Check Administrator Access (AS2012SP1\POWERPIVOT): Pass.
  3. Check Server Version (AS2012SP1\POWERPIVOT): Pass (11.0.2809.24 >= 11.0.2800.0).
  4. Check Deployment Mode (AS2012SP1\POWERPIVOT): Pass.
  5. Check Server Configuration (AS2012SP1\POWERPIVOT): Pass.
The ULS logs should give you all the information you need to verify the Excel Services configuration for PowerPivot, but investigating ULS logs on busy SharePoint servers can be tedious and time consuming. Running an ad-hoc PowerShell script in the SharePoint Management Shell is often an efficient and more interesting alternative. In my next blog post, I’m going to introduce such a PowerShell script to verify the SharePoint 2013 configuration for all shared services that might want to consume a workbook as a data source. Stay tuned!


Thursday, March 5, 2015

Setting up your App domain for SharePoint 2013

Setting up your App domain for SharePoint 2013


The most important change in SharePoint 2013 for developers is the introduction of SharePoint apps. An app for SharePoint is a small and isolated application that provides a specific bit of functionality. SharePoint apps can and have to be added to or removed from a site by the site owner.  Apps have their own, isolated URLs, which are separate from the URLs of the sites where the app is being deployed to and where the app is being used. In order to provide isolation apps run in their own domain, instead of in the same domain name as your farm. Using a different domain name for apps helps prevent cross-site scripting between apps and SharePoint sites. 
Each installation of an app has its own unique URL within the app domain. The app’s URL is based on a template “http://[app prefix][app hash].[app domain]/[relative site url]/[app name]. When you add an app to a site, a subweb of that site is created to host the app content. This subweb is not visible on the Site Contents page though.
Because apps run in their own app domain you will have to configure Domain Name Services (DNS) in your environment in order to be able to host apps. There is a page on TechNet that describes how to setup you DNS, but because it took me a while to get it all working I decided to write a step by step guide, which is what you’re reading now.

You can choose whether you want your app domain to be a subdomain of the domain that hosts the SharePoint environment (option B), or whether you want to create a completely new domain for your apps (option A). Creating a new domain specifically to host your apps in is a bit more secure, but it also requires a little bit more configuration. I will describe both approaches in this article. If you don’t have control over your DNS you will have to ask an administrator to perform these steps for you.

Option A: Create a new domain to host your apps in

  • Go to “Start”
  • Click on “Administrative Tools”
  • Select “DNS”
Open DNS
  • Right click “Forward Lookup Zones” and select “New Zone…”
  • Click “Next”
  • Keep the default and click “Next” again
  • In most cases, especially if your development server is in it’s own domain you can use the default on the next tab again and can just click “Next”
  • You now have to specify a zone name. It’s up to you what you choose here. My domain name is “solutions.com” and for my app domain I will use “solutionapps.com”
  • Click “Next”
New Zone Wizard
  • Click “Next”
  • Click “Finish”
DNS Manager
  • Right click on your new zone and select “New Alias (CNAME)…”
  • Fill in a * for “Alias name (uses parent domain if left blank)”
  • Click “Browse”
  • Double click on your server name
  • Double click “Forward Lookup Zones”
  • Double click the domain of your SharePoint environment. In my case this is “solutions.com”.
  • Select “(Same as parent folder)” and click “OK”
  • Click “OK”.
* Note that selecting the FQDN of the domain in here will only work in single server scenarios. If you are using more than one server you should be pointing to the DNS record of the web server in here. This is either the DNS A record for the web server, or the DNS record of the primary cluster address for NLB environments.
Create a CNAME
  • You are now done setting up your DNS and it should look like this:
DNS Manager

Option B: Create a subdomain to host your apps in

  • Go to “Start”
  • Click on “Administrative Tools”
  • Select “DNS”
Open DNS
DNS Manager
  • Right click on the name of your domain and select “New Alias (CNAME)…”
  • Fill in “*.app” for “Alias name (uses parent domain if left blank)”
  • Click “Browse”
  • Double click on your server name
  • Double click “Forward Lookup Zones”
  • Double click the domain of your SharePoint environment. In my case this is “solutions.com”
  • Select “(Same as parent folder)” and click “OK”
  • Click “OK”
* Note that selecting the FQDN of the domain in here will only work in single server scenarios. If you are using more than one server you should be pointing to the DNS record of the web server in here. This is either the DNS A record for the web server, or the DNS record of the primary cluster address for NLB environments.
Create a new CNAME
  • You are now done setting up your DNS and it should look like this:
DNS Manager

Configuring SharePoint

I’m assuming you already created an App Management and a Subscription Settings Service Application and that you already started the App Management and Subscription Settings services on your servers. If not this My acticle will tell you how to. Note that you have to use PowerShell to create the Subscription Settings Service Application. There is no user interface for it.
Service Applications
Services on Server
  • Go to Central Administration
  • Click on “Apps” in the left side navigation
  • Click “Configure App URLs”
  • Fill in the URL of the app domain that you configured. If you choose to use Option A the url will be something like “solutionapps.com”, if you choose to use Option B it will look like app.solutions.com.
  • Fill in an app prefix. This can be anything you like, although it is best to keep this short. I used “app” myself.
Configure App URLs
Two example urls for two different apps on the same site are:
http://app-fef8493a3feb20.solutionapps.com/sites/apptest/[App1AppName]/Pages/Home.aspx
http://app-fef8493a3feb1d.solutionapps.com/sites/apptest/[App2AppName]/Pages/Default.aspx
As you can see both apps have their own app hash, but both are in the same domain.

Hope this Help,
Oumaima

Set up an on-premises development environment for apps for SharePoint

Set up an on-premises development environment for apps for SharePoint


  1. Ensure that the app management service and user profile application are configured. The steps are as follows:
    1. In Central Administration, under Application Management, select Manage service applications.
    2. On the Service Applications page, ensure that the following services are started:
      • User Profile Service Application
      • App Management Service
    3. Under Application Management, select Manage services on server.
    4. On the Services on Server page, ensure that the following services are started:
      • User Profile Service
  2. Ensure that at least one profile is created in the User Profile Service Application. The steps are as follows:
    1. In Central Administration, under Application Management, select Manage service applications.
    2. Next, select User Profile Service Application.
    3. On the Manage Profile Service: User Profile Service Application page, under People, select Manage User Profiles.
    4. On the Manage User Profiles page, select New Profiles.
    5. On the Add User Profile page, type your account name and email address.
    6. Select Save and Close.

Create an isolated app domain on your development computer

  1. Ensure that the spadmin and sptimer services are running by opening a command prompt and typing the following commands.
    net start spadminv4
    net start sptimerv4
    
  2. Create your isolated app domain by running the SharePoint Management Shell as an administrator and typing the following command.
    Set-SPAppDomain "your app domain"
    
  3. Ensure that the SPSubscriptionSettingsService and AppManagementServiceInstance services are running by typing the following command in the SharePoint Management Shell.
    Get-SPServiceInstance | where{$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"} | Start-SPServiceInstance
    
  4. Verify that the SPSubscriptionSettingsService and AppManagementServiceInstance services are running by typing the following command in the SharePoint Management Shell. The output will indicate whether each service is online.
    Get-SPServiceInstance | where{$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"}
    
  5. You must specify an account under which the SPSubscriptionService and AppManagementServiceInstance service instances will run. This account must be an SPManagedAccount. You can create an SPManagedAccount by typing the following command in the SharePoint Management Shell. (You’ll be prompted for the account domain\user and password.)
    $account = New-SPManagedAccount
    
  6. Specify an account, application pool, and database settings for the SPSubscriptionService and AppManagementServiceInstance services by typing the following code in the SharePoint Management Shell. If you created a SPManagedAccount in the preceding step, use that account name here.
    $account = Get-SPManagedAccount "domain\user" 
    $appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account
    $appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account
    $appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName SettingsServiceDB 
    $proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc
    $appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName AppServiceDB
    $proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc
    
    
  7. Specify your tenant name by typing the following code in the SharePoint Management Shell.
    Set-SPAppSiteSubscriptionName -Name "app" -Confirm:$false
    
After you create your isolated app domain, perform the steps in the following procedure to add that domain to your bypass list in Internet Explorer. This ensures that you can navigate to this domain after you deploy a SharePoint-hosted app. You can skip this procedure if your environment does not use a proxy server.
I will explain in the next post how to configure DNS and services in central administration.

Oumaima,

Sharepoint Designer 2013, XSLT List View Options ribbon option is not showing

Sharepoint Designer 2013, XSLT List View Options ribbon option is not showing I have an ordinary Wiki Page, also tried making an Article...