I am trying to backup my TFS 2010 instance using the TFS 2010 Power Tools issued in March 2011.
In the verification step, I am getting an error that I do not know how to solve:
"The current username failed to retrieve MSSQL Server service account."
Can anyone help?
The answer, in my instance, required a few things:
As Ryan noted in the comments above, the SQL service account cannot be "Local System". Create a new user account on your domain, and then follow the instructions Ryan provided: Setting Up Windows Service Accounts.
Change the service account for TFS from Local System to a service account on your domain. I followed these instructions: Change the Service Account or Password for Team Foundation Server.
To configure the backup, log on using the same account as was used originally to install the TFS server instance. (I'm not sure what permissions are missing from my other administrator account)
Related
I was Trying to deploy SSIS package from Visual studio 2019 into MS SQL Server 2016, I have been facing deployment error as shown below:
"“A .NET Framework error occurred during execution of user-defined routine or aggregate "deploy_project_internal": System.ComponentModel.Win32Exception: A required privilege is not held by the client.”
After few hours of debugging found that the error is actually from SQL Server. SQL Server is unable to run the stored procedure from SSISDB "[catalog].[check_schema_version] ".
Hence we realized that there are certain privileges for the current service account on which SQL Server is running. Hence we have created a new local admin account and provided all privileges.
• As per Microsoft suggestion, we have added the SQl server service account & SQL server integration service account in the below Configs :
o Edited DCOM config properties and provided granted the Local Launch and Local Activation permissions for the below component services
Microsoft SQL Server Integration Services 11.0, Microsoft SQL Server Integration Services 12.0 and Microsoft SQL Server Integration Services 13.0
o Further we extended permissions for both the service accounts as below :
Log on as a service .
Permission to write to application event log.
Impersonate a client after authentication.
Adjust memory quotas for a process
Below are the two group policies yet to be added :
Bypass traverse checking
Replace a process-level token
I would like to know if this resolves the issue and please suggest anything that we are missing here to resolve the issue.
After adding the New service account to the listed group policies, the deployment got succeeded.
I ran into this problem after a new Security Policy was put in place that broke WinRM (disabled "Allow remote server management through WinRM"). Even after rolling back the change I could not deploy SSIS packages. I finally fixed the problem by running the "Repair" SQL option from the installation disk and then restarting the server. After that deployments worked as normal.
Background
We use Team City to deploy our web sites and SQL migrations/dacpac's to servers that have been working successfully for quite some time. One of our servers was last deployed to on 4 March 2019.
Today I did a deploy to that server and our step that deploys dacpac and migrations has stopped working on that server.
The server is Windows Server 2016 environments, running Sql Server 2017 with all the latest windows patches.
We are using IIS Delegation (NOT using Kerberos).
I can confirm the following
Nothing has changed in terms of IIS Settings, user permissions or
anything on this server
The last successful release out to the server was 4 March 2019.
The last time anyone logged onto this server was February 2019
Pre-authenticating to remote agent URL
'https://devdeploy.mydomain:8172/MsDeploy.axd?site=mysite' as
'TeamCity' authenticates as expected
The delegation set up is as follows:
The step that is now failing looks like this
run a .bat file that has the following command:
WHOAMI
"C:\Program Files\Microsoft SQL Server\150\DAC\bin\sqlpackage.exe" /Action:Publish /SourceFile:"C:\inetpub\websitepath\dacpac\mydacpac.dacpac" /TargetServerName:SQLServer /TargetDatabaseName:MyDatabase
(NOTE: The WHOAMI This returns "ServerName\TeamCity")
The error given in Team City logs is:
Cannot open database "MyDatabase" requested by the login. The login
failed. Login failed for user 'ServerName\TeamCity'.
This implies (IMHO) that the delegation from IIS to the batch file which is run, is no longer occurring.
It appears that IIS Delegation has not performed the correct delegation and is running the user under the 'TeamCity' not under the delegated user 'DbOwnerUser' (see image above for runCommand delegation setup).
My Questions therefore are
Is anyone else having this issue?
Is there a security update that has caused this to no longer work
e.g. KB4489885 (this talks about Kerberos and we are NOT using
Kerberos)
Does anyone have any thoughts as to how this could happen or be fixed
(apart from uninstalling the security update)?
Thanks in advance to anyone who has some good ideas :)
I am trying to configure BTS 2016 3.12.774.0 against SQL Server v 17.9.1. They are running on separate servers running Windows server 2016 64 bit OS.
The Enterprise Single Sign On database (SSODB) and the Business Rules Engine DB (BizTalkRuleEngineDB) get created but only to BRE is configured when I go into Biztalk Config.
I have had the servers rebooted but no change.
The Ent SSO Service does not exist in Services
User doing the install is in groups Biztalk Server Admin, Application Users, Server Operators and SSO Admin, Affiliate Admin all at the domain level.
Names of both servers are 13 characters.
Not sure what to look for in the configuration logs. I have searched for the words Error, Fail, Exception but there are none.
A new attempt to configure gave the following error:
Microsoft BizTalk Server Configuration Wizard ------------------------------ Failed to create the SQL database 'SSODB' on SQL Server 'servername10' (with SSO Administrator account 'SSO Administrators'). (SSO) For help, click: go.microsoft.com/fwlink/… ------------------------------ ADDITIONAL INFORMATION: (0xC0002A21) An error occurred while attempting to access the SSO database. (SSO) For help, click: go.microsoft.com/fwlink/… ------------------------------ An error occurred while attempting to access the SSO database. See the event log (on computer 'servername10') for more details. (SSO)
There is no SQL Server v 17.9.1. That version number is one for SSMS.
BizTalk Server 2016 does not support SQL Server 2017. Hardware and Software Requirements for BizTalk Server 2016
Please post the error text, either from the little red X or the error log. There will always be an error. BT Config will never silently fail.
I have a sharepoint 2010 portal with some dashboards and reports. No I have a permission problem, because I cannot view these reports.
I would like to have a look in Reporting Services Configuration Manager, but I cannot connect to the server where sharepoint and SQL server is installed. I enter the server name and press on find. It gives me the following error:
Unable to connect to the Report Server MYSERVERNAME.
By the way, I try to fix this problem:
AccessDeniedException: The permissions granted to user
'Mydomain\MyUserAccount' are insufficient for performing this
operation.
First off, you probably want to be using SharePoint Central Administration, not RS Configuration Manager. Also, RS Configuration Manager isn't where you'd manage access to report objects.
That said:
Try remoting into the host machine and running the tool locally on the server.
Ensure the proper ports are open for you to be connecting remotely (and that they SHOULD be open - there are very valid security reasons to block them)
Are you 100% certain you're connecting to the right address? Is it possible the SSRS service itself is on a different machine than the Sharepoint service and the SQL server?
I have a sharepoint site installed and configured on farm. I want to find out which is the account used [spinstall, the user has not used the naming conventions] to do the installation. Is there a way I can find that out?
Thank you.
Check the account under which the Central Administration web site's application pool is running
JumpingThroughCode's answer would only be correct if they made the mistake of doing the installation with Farm Service account. The Farm Service account should be a low-privileged account that is the CA AppPool account and the Timer Service account. The Farm Admin, or Installer, account is a highly privileged account used to install the product and any updates, and is the initial Farm Administrator account.
I don't know of any way to reliably determine this via code - I've seen it suggested that this account would be the only one in both Farm Administrators and Managed Service Accounts, but it could have been removed from Farm Administrators.
I would recommend checking the installation logs in the 14/LOGS folder.