Changing SharePoint Execution Timeout

In SharePoint, the default time allowed to export reports to different formats (Excel, PDF, etc) is 2 mins –and to me that’s already a lot of time for a report to render-, but there are some unfortunate cases where you need to render large amounts of information and therefore, you need to ensure that the SSRS reports are actually able to export.

To do so, you need to make sure that the execution timeout is increased to not have the process fail.

Since SharePoint is a web platform, we need to include a parameter in the web.config for IIS to increase the timeout.

  1. Open IIS Manager on servers that have Reporting Services installed.
  2. Select the Site on Port 80.
  3. Right Click the site and select Explore.
  4. Edit the web.config file in Notepad.
  5. Search for the first occurrence of “httpRuntime” located under the system.web.

  6.  Add “executionTimeout=”1200”” to the httpRuntime entry located in the above image. (Value is in seconds, 1200 is 20 minutes)

  7.  Save the file and Close the file.
  8. Close the Windows explorer window.
  9. Restart IIS.
  10. Close IIS Manager.

Fix: PowerPivot for SharePoint Data Refresh



  1. On the Analysis Services Server running in SharePoint mode, Add the Analysis Services service account to the “Act as part of the operating system” privilege:
    1. Run “secpol.msc”
    2. Click Local Security Policy, then click Local policies, and then click User rights assignment.
    3. Add the service account.
  2. Restart Excel Services and reboot the Analysis Services server.

Delegation from the Excel Services service account or from Claims to Windows token service (C2WTS) to the Analysis services instance is not required. Therefore no configuration for KCD from Excel Services or C2WTS to PowerPivot AS service is necessary. Note: If the backend data source is on the same server as the Analysis Services instance, delegation is not required.

Querying Active Directory from SQL Server

Sometimes source systems do not store Windows credentials as an attribute of a person, and when that happens security becomes an interesting challenge.

For this project, I needed to retrieve the EmployeeNumber attribute from Active Directory to be able to link the user back to the source system (very useful for Reporting, but same logic applies for any service from the SQL Server BI stack).

First we need to create a ‘Linked Server’ from a SQL Server instance with the following system stored prod:

EXEC sp_addlinkedserver 'ADSI', 'Active Directory Service Interfaces',
'ADSDSOObject', 'adsdatasource'

After you just create a Data Source pointing to the instance where you added that Linked Server and start querying the attributes you need from the Active Directory domain you need:

          objectCategory = ''Person'' 
          AND objectClass= ''user'' 
          AND sAMAccountName='''+ YourUsername + '''')

If you need to get groups:

          objectCategory = ''GROUP'' 
          AND CN = ''* *''')

If you need to know the people that belong to a specific Group:

          objectCategory = ''user'' 
          AND memberof = ''CN=NameOfTheGroup,OU=Groups,OU=YourDomain,DC=YourDomainControler''')

Passing Multi-value Parameters to a MDX Query in SSRS

Let’s say our report needed ProductCategory as a parameter.  The ProductCategoryKey in the relational database for Bikes is 1, and our cube member for Bikes is [Product].[Category].&[1].  So we can transform our parameter value to pass into our mdx query like so:

“[Product].[Category].&[”+Cstr(Parameters!ProductCategory.Value) + “]”

Simple right?

BUT, I needed to be able to pass multiple values, which meant I had to take some extra steps before I could parse my string.  If ProductCategory is a multi-value parameter, then Parameters!ProductCategory.Value is an object – an array of values.  So we need to create a single string out of that array, format that string, and then break it up again back into an array since that is what the MDX query is expecting.  Whew!

Here’s the magic:


Cool eh? but, what’s happening here?

Join() is a handy little function that takes our array and joins the values into a string.  We can delimit the values with a string, in this case “],”, like so:

Join(Parameters!ProductCategory.Value, “],”)

Bikes, Components, and Clothing for our parameter values, our string after using the join function will be“1],2],3″.  We can then add an ending bracket to the end via simple string concatenation so now we have “1],2],3]”.

Applying the Replace() function, we replace “,” with “,[Product].[Category].&[“ and now we have “1],[Product].[Category].&[2],[Product].[Category].&[3]“.  Finish with one final string concatenation in the front and we have “[Product].[Category].&1],[Product].[Category].&[2],[Product].[Category].&[3]“

Unfortunately we can’t just pass this into our MDX query.  It’s expecting an array object, not a string!  But luckily, the Split() function is the counterpart to Join() and breaks up our string into that array object we want via the commas as a delimiter.