We have upgraded TFS 2012 to TFS 2013 and did not have sharepoint installed before. So i installed tfs sharepoint components on a sharepoint server and tfs server and connected them. Everything is fine except excel reports and they give me the following error:
External Data Refresh Failed
The data connection uses Windows Authentication and user credentials could not be delegated. The following connections failed to refresh: TfsOlapReport
i have made sure Claims to windows authentication service is running.
To fix the error, please follow steps below which are quoted from this blog.
On the Team Foundation Server Administration Console, click Extensions for Sharepoint Products.
Select the Sharepoint Web Application which you are using.
Click Modify Access
Enter a user with access rights to the reports inside the Enterprise Application Definition field
Browse to Central Administration in Sharepoint
Select Manage Service Applications
Select Secure Store Service (Type: Secure Store Service Application)
Under Manage Target Applications, Click on New
Enter Target Application ID = "TFS", Display Name = "TFS", Contact Email="Whatever", Target Application Type = "Group", Target Application Page URL = "None" and click Next
Do not enter anything on this page as it's asking for fields name and not the actual credentials.
Enter Target Application Administrators and Members and click ok.
it will take you back to the page that was displayed after performed step 3.
Now right click on "TFS" and select "Set Credentials" and then enter the username and password that this account will be running under.
Now login to the TFS Server and click extensions for Sharepoint products.
Select the sharepoint web application you are using.
Click Modify access.
Enter "TFS" under the Enterprise Application Definition field.
Also just to make sure "Excel Service applications are configured properly, Click on "Excel Service Application "Type: Excel Services Application Web Service Application".
Click on Trusted File Location and make sure the site collection is added to the Trusted File Location and location type is "Microsoft Sharepoint foundation". under Trust children check "children trusted". under Allow external data select "Trusted data connection libraries and embedded".
Go back to page displayed after step 14 and select "Global Settings".
File access method = "impersonation", Under Analysis Services EffectiveUserName, check "Use the EffectiveUserName property".
Check "Use an existing Unattended Service account" radio button and under Target Application ID: enter "TFS".
Also make sure under Trusted Data Providers, the providerid your excel application is using is listed.
Related
I am getting below error while generating the SQL scripts using a web installer with Integrated security as true /Windows authentication mode on.
It works perfectly fine with SQL authentication mode.
The server principal "DOMAIN\MACHINENAME$" is not able to access the database "" under the current security context.
Regards
Web Installer Issue -DB Issue -The server principal
“DOMAIN\MACHINENAME$” is not able to access the database
First, if you access a private database by your current account, you should make sure that your current account is under the domain.
Then, if you have web.config file in your project, add <identity impersonate="false" /> under <system.web>.
===================
If you use SQL Server,
1) login into it and check whether you can access the database's info. Or just change another
2) Go to SQL Server --> Security --> Logins and right click on NT AUTHORITY\NETWORK SERVICE and select Properties
In newly opened screen of Login Properties, go to the User Mapping tab. Then, on the User Mapping tab, select the desired database – especially the database for which this error message is displayed. On the lower screen, check the role db_owner. Click OK.
=================
If use you SSMS,
Open SSMS --> Security --> Logins.
Right click NT AUTHORITY\NETWORK SERVICE and Click Properties.
Go to Status tab and set Permission to Connect To Database Engine To Grant.
==================
If you use IIS manager,
open IIS manager-->your application pool --> advanced setting-->set custom account under Identity menu-->then enter your domain user name(DOMAIN\USERNAME) and password.
Or you could just click Identity--> slectBuild-in Account and choose NetworkService.
While installing SharePoint Server 2013 I am finding the above error in the Configuration Wizard.
This error is occurred while generating Sample Data for SQL.
It gives me an error in the 8th step out of 10 steps.
I have tried to find out the solution for that and I have came to know that I need to set Full Access rights permission for WSS_ADMIN_WPG user.
But I did not find any folder that starts with "Analytics_GUID" in the "C:\Program Files\Microsoft Office Servers\15.0\Data\Office" Server Path.
Can anyone help me out in this.
I had the same problem. You also need to ensure that the account you are installing with has sufficient permissions in the SHAREPOINT SQL Server instance.
To grant your account sufficient SQL permissions:
open SQL Server Management Studio
connect to the SHAREPOINT instance ( named server\SHAREPOINT )
in the left tree expand Security | Logins and select your account
right click and select Properties
in the login properties dialog select Server Roles
select all of the checkboxes to grant yourself every role.
click ok.
See this article for details: http://www.sharepointpitstop.com/2013/09/the-sddl-string-contains-invalid-sid-or.html
Following is the pertinent part of the article:
1) Check if the account used for installing SharePoint 2013 has dbcreator and security admin permission in SQL Server.
2) Browse to "C:\Program Files\Microsoft Office Servers\15.0\Data\Office Server" and find the folder that starts with Analytics_GUID.
3) Right-click -> Properties ->Sharing ->Advanced Sharing. Check the "Share this folder' check box and click on Permissions.
4) Granted full access to everyone.
5) Added WSS_ADMIN_WPG to the sharing with full access.
6) Ran the SharePoint 2013 Products Configuration Wizard again and this completed successfully.
I have created an external content type in SharePoint 2010 that populates a list from SQL. The list is successfully populated and I can view it through SharePoint. However, if I select the option to "Connect to Outlook" I receive an Error: Access Denied. My account is a farm admin and has full control. The only message I get in the error log is as follows:
Publish Process failed to publish solution for the List Autotask
Clients.
0x80070005Access
denied.
You seems connected as "System Account" in your browser, but are you also connected as the same user in your Windows session?
Outlook don't use the account use in IE but the one you used to logged in into Windows.
The authectication was set to kerberos, once I switched it to NTLM it worked as expected.
I have a website running on a Windows 2003 server on IIS 6, serving pages for a LAN where everybody is working with a domain account. On other machines this works fine, no-one has to login to the website, the dynamic scripts pick-up the account-name from the HTTP request.
Only, when browsing from the server itself (via remote desktop e.g.), Internet Explorer still pops up the domain-login-dialog when navigating to this site. (both the usual URL and http://localhost/). This was no problem on the Windows 2000 server we recently migrated the website from.
I had this problem or similar and solved it by:
adding http://localhost to list of Intranet sites, via IE > Tools > options > security > Local intranet > Sites > advanced > add http://localhost. (This is necessary if you have IE Enhanced Security installed which assigns all intranet Web sites and all UNC paths that are not explicitly listed in the Local intranet zone to the Internet zone, even localhost or other domains that don't contain '.' symbol which would normally be considered intranet by default.)
also on Security > Local Intranet > see what level of security you're on, to ensure that logon details are passed through. If it's Custom then click the Custom Level... button, scroll right to the bottom, under User Authentication > logon > for me it's 'Automatic logon only in Intranet zone', which works.
Did you configure IE on your Windows 2003 box for "Enable Integrated Windows Authentication"? This needs to be configured in IE6 to automatically use the logged-in user credentials.
You'll probably have better luck on ServerFault for this issue, as it's probably down to server configuration. Take a look at this KBAlertz.com article, yes it's specific to SharePoint, but some bits are more general. I suspect (given that you've said you've migrated to a new machine), that the issue is around the new machine not being "trusted for delegation" so look at the part titled "Configure trust for delegation for Web parts"
Configure trust for delegation for Web
parts To configure the IIS server to
be trusted for delegation, follow
these steps:
Start Active Directory Users and Computers.
In the left pane, click Computers.
In the right pane, right-click the name of the IIS server, and then
click Properties.
Click the General tab, click to select the Trust computer for
delegation check box, and then click
OK.
Quit Active Directory Users and Computers.
If the application pool identity is
configured to use a domain user
account, the user account must be
trusted for delegation before you can
use Kerberos authentication. To
configure the domain account to be
trusted for delegation, follow these
steps:
On the domain controller, start Active Directory Users and Computers.
In the left pane, click Users.
In the right pane, right-click the name of the user account, and then
click Properties.
Click the Account tab, under Account Options, click to select the
Account is trusted for delegation
check box, and then click OK.
Quit Active Directory Users and Computers.
If the application pool identity is a
domain user account, you must
configure an SPN for that account. To
configure a SPN for the domain user
account, follow these steps:
Download and install the Setspn.exe command-line tool. To do
so, visit the following Microsoft Web
site:
http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&DisplayLang=en
(http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&DisplayLang=en)
Use the Setspn.exe tool to add an SPN for the domain account. To do
so, type the following line at the
command prompt, and then press ENTER,
where ServerName is the fully
qualified domain name (FQDN) of the
server, Domain is the name of the
domain, and UserName is the name of
the domain user account:
Setspn -A HTTP/ServerName Domain\UserName
You do not have permissions to do this
operation. Ask your website
administrator to change your
pemissions and then try again, or log
on with another account that has this
permission. To log on with another
user account click ok.
I need some help regarding the above error. After applying SP1 pack on our SharePoint Server 2007 (MOSS 3.0) the workflows aren't working anymmore on one of the WebApplications (located in SSP2) Workflows work, however on other existing applications (on SSP1 or SSP2) or newly created applications (on SSP1 or SSP2).
Details of error: 1. Default / Built in SharePoint Workflows are not starting 2. Sharepoint Designer Workflows throwing the following error message: "You do not have permissions to do this operation. Ask your website administrator to change your pemissions and then try again, or log on with another account that has this permission. To log on with another user account click ok. " 3. Before applying the SP1 on MOSS the workflows were working perfectly fine on this WebApplication.
so far: 1. I am logged in as Administrator (bot on Sharepoint site or when working with Sharepoint Designer). 2. Administrator is included in the list Site Collection Administrators 3. I noticed in Sharepoint designer that the username used for creating the workflow is 'converted' into SHAREPOINT\system (in the Modified By Column).
Has anybody come accross/fixed this error?
Any help much appreciated. Thanks D
You need to Disable the Loop Back check, this is something introduced in SP1 to avoid running things as the System Account for security purposes.
Click Start, click Run, type regedit, and then click OK.
Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Right-click Lsa, point to New, and then click DWORD Value.
Type DisableLoopbackCheck, and then press ENTER.
Right-click DisableLoopbackCheck, and then click Modify.
In the Value data box, type 1, and then click OK.
Please understand that this feature exists for a reason, and you should configure your accounts properly to avoid the problem.