In not all environments it is possible to install QVWS on the SharePoint configuration - this guide can help to work around this.
The first thing to check is whether QVWS works fine without SharePoint. If not, please investigate this first by going to the AccessPoint page from the SharePoint machine's browser.
In our example we have the following machines, all running Windows Server 2008 R2:
QlikViewServer1: QVS, QVWS, QDS, DSC, QMC v11.20 SR5. No clusters of any services.
QlikViewServer2: SharePoint 2010 SP1, full Windows Update as of March 2014, QV Web Parts v11.20 SR5.
QlikViewServer3: Client, no additional software required apart from browser. Optional software included DelegConfig for testing.Step 1: configure QlikView Web Server for Kerberos authentication:
It is required to configure the Web Servers (QVWS or QSS) config.xml file for Kerberos authentication. The file is located at C:\ProgramData\QlikTech\WebServer . Stop the service and change protocol from NTLM to Negotiate:
<HttpAuthentication url="/QvAJAXZfc/Authenticate.aspx" scheme="Negotiate" />
Two Service Principal Names must be registered on the service account, one using the NETBIOS name of the computer hosting QlikView Webserver and one using the Fully Qualified Name of the server.
In this example the NETBIOS name of the server hosting QlikView Webserver is "QlikViewServer1", the Fully Qualified Name is "QlikViewServer1.domain.local" and the account used by QlikView Webserver is "DOMAIN\QvService".
The following will require appropriate permissions in Active Directory to add Service Principal Names on the account running QlikView Webserver, open a command prompt with administrative privileges and type:setspn -U -S http/QlikViewServer1 DOMAIN\QvService
setspn -U -S http/QlikViewServer1.domain.local DOMAIN\QvService
The WebServer service can be started again afterwards.
You can read more about Kerberos support using QlikView Webserver
here.Step 2: Install web parts.
The QlikView WebPart installation is done in two steps. Step 1 is to run installer, and step 2 is to integrate the QlikView WebPart feature into SharePoint. In both steps it is necessary to not only have local administrator rights, but also permissions in SharePoint – because SharePoint administers its own security independent from Windows. The permission level necessary in SharePoint is “Farm administrator”.
See Troubleshooting Issues with QlikView WebParts for SharePoint
if having issues with installing Web Parts properly.
Running the installation package (QlikViewWebParts_x64Setup.exe)
The installer package checks that you have access to a valid QvAjax web folder:
If the URL doesn't work, make sure the QlikView setup is accessible by itself from the SharePoint machine, at http://QlikViewServer1/QlikView. This should open the AccessPoint, displaying a list of QlikView documents.
The next step is where you select which of the SharePoint Web Applications that you want to install the QlikView WebPart into:
If the list appears empty then it is most likely a case that the user running the installer does not have Farm Administrator rights in SharePoint.
Apart from selecting web application it is also necessary to decide if a proxy should be used. As the text says, the proxy is necessary if SharePoint and QvAjaxZfc are on separate servers, which is the case in our setup.
The “Make QlikView WebParts accessible” option would run the install.cmd script automatically. Generally it is better not to do this and run the script separately.
Once all selections have been made the installer will install files into C:\Program Files\QlikView\WebParts, but nothing will have been installed into SharePoint yet (unless the “Make QlikView WebParts accessible” option was selected).
Integrating the QlikView WebPart feature into SharePoint
After running the installer, it is necessary to integrate the QlikView WebPart feature into SharePoint.
This step can be done in different ways but the easiest is to run the “Install.cmd” file which is in C:\Program Files\QlikView\WebParts\Setup”.
Running the install.cmd should always be done from a command prompt so that it is possible to notice if any of the commands in this file fails, and to catch any error messages.
The account used to run the install.cmd has to be in the Farm Administrators group in SharePoint.
After this is done, Web Parts should work in the SharePoint setup, please test with adding a Web Parts object in your SharePoint Web application. What might happen is that it is using the service account, which we are about to address.Step 3: SharePoint configuration.
If Kerberos works on Sharepoint it should work to run Kerberos right away, no configuration for Kerberos itself is needed, although the delegation needs to be set up. It should not be required to check “Use any authentication protocol” when setting up delegation, instead use “Trust this user for delegation to any service” or “Trust this user for delegation to specified services” (and point out the QVWS on the QlikView machine). The latter suggestion requires a SPN for the QVWS, which was explained earlier.
Dependent on the App-pool configuration on the Sharepoint one needs to delegate either the app-pool account or the machine-account for Sharepoint.
If Kernel-mode authentication is enabled
for the app-pool one needs to delegate permissions on the machine-account, resulting in no requirement of an SPN for the app-pool account.
However, if Kernel-mode is disabled
, one needs to delegate the app-pool account (as above mentioned).
It is not possible to change the service account for the SharePoint Web Applications inside IIS, this needs to be done through SharePoint, otherwise one will experience permissions issues.
We will now deal with the two Kernel-mode options.Step 4a: Kernel-mode is enabled - delegation to machine-account.
First, let's double check on the App pool in IIS of QlikViewServer2 what account is being used to run SharePoint web services. Go to IIS settings > QlikViewServer 2 (or equivalent servername) > Application Pools and take a look at the name "SharePoint - 80".
In our case, by default installation, it is "NetworkService" - meaning the computer account. If there happens to be a domain account here being used, see Step 4b.
We need to confirm that this is reflected in the Kernel-mode setting inside IIS to.
Go to IIS settings > QlikViewServer2 > Sites > SharePoint - 80 > Authentication. Select "Windows Authentication" and press "Advanced settings" to the right. We should now see that "Enable Kernel-mode authentication" is unchecked.
On the DC, enable QlikViewServer2's machine account to be "trusted for delegation to any service (Kerberos only)". This can only be done if we have set SPNs for the computer-account.
Remember to restart the machine with the SharePoint environment, the machine account permissions needs to be picked up.
Go to step 6 now, to test it out.Step 4b: Kernel-mode is disabled - delegation to service account.
In this step, a regular service account is used instead of a machine account, thus the delegation steps are different. Some environments and policies requires this.
First off, create a regular domain account to be used as the SharePoint service account: DOMAIN\sp_user
Open up the SharePoint Central Administration, and press Security. Under "General Security" you can find "Configure managed accounts".
Add DOMAIN\sp_user in SharePoint as a managed account:
Go back to Security, and choose "Configure service accounts". Choose the "Web Application Pool - SharePoint - 80" in the component to update, then choose the DOMAIN\sp_user as "the account to use for this component", that we just registered.
Run “iisreset /noforce” on the Sharepoint machine afterwards to make IIS pick up the settings.
Confirm in IIS that app pool account has changed from NetworkService to DOMAIN\sp_user on the Application pool called "Sharepoint - 80":
Also ensure that that “Kernel-mode” is now disabled on the authentication of the SharePoint Web Application:
We also need to register two Service Principal Names on the DOMAIN\sp_user account in order to be able to delegate rights to it. Run the commands from the SharePoint-machine (in our case, named QlikViewServer2:setspn -U -S http/qlikviewserver2 DOMAIN\sp_user
setspn -U -S http/qlikviewserver2.domain.local DOMAIN\sp_user
On the Domain Controller, we can now since we have added SPNs enable delegation on the service account sp_user on the DC. Open up the service account and select “Trust this user for delegation to any service”:
Please proceed to step 5 if you had Kernel-mode enabled earlier, which was explained in Step 4a. (Step 5 - if changing from Kernel-mode enabled to disabled - undo settings.)
In case we earlier had Kernel-mode enabled, meaning delegation was set on the Computer account/Network account (QlikViewServer2) we now need to disable this. We do not want any loose ends in our security, and we could get fooled by the old security settings still enabled.
Remove delegation from the computer account QlikViewServer2:Step 6 - testing out the environment
On our client machine, we can now test out the configuration. It is important to test this out from a third machine, where neither SharePoint, QVS, QVWS or Web Parts is installed in order to properly test the Kerberos delegation. Even if it works, remember to restart machines afterwards again to ensure that there are no old SSL sessions or Kerberos delegation still available - this might fool you until a restart has been performed.
From QlikViewServer3, our client machine, we can now test the Web Part object in SharePoint. Ensure that you are using a user-account on SharePoint and in Windows, and not the service-account for either the QlikView Services or SharePoint. In our case, we have added an object from the sample document called "Movies Database.qvw":
We should also double check this on the QVS Statistics in the QMC, where it tells us what user is accessing what document and which objects. Note that DOMAIN\Administrator was used both on SharePoint and in the QMC, no mentioning of sp_user or QvService accounts.
If running into issues or ensuring that everything works, one can run a tool called "DelegConfig" to help you out and suggest changes to be done. In our case the tests performed well. Remember to run this from both the SharePoint machine and a client machine, in order to fully test Kerberos delegation. In cases where delegation doesn't work this tool would tell you that NTLM is used for authentication for instance, or that the wrong account is used.
This toll is not supported, but is quite handy. It can be found at http://blogs.iis.net/brian-murphy-booth/archive/2007/03/09/delegconfig-delegation-configuration-reporting-tool.aspx