I'm trying to setup Nightly Backups for my TFS 2012.4 development box going off to another server, but it's failing.
The server is has SQL Express and TFS Express on it, trying to send the backups over to a network path on another share.
When going through the Wizard it will successfully pass all of the Readiness Checks, including permissions. It will fail when it tries to run the backup job for the first time under Confirming Permissions.
Error is:
TF401002: The SQL Server Database Engine failed to save the database
backup to path \[share]\c$\TFSBackup. Please grant SQL service
account read/write access to that folder.
I've tried adding "Everyone" with full control to the folder on the backup server, but it still fails with the same error.
Added the full log to http://pastebin.com/80PrYXqx
This may be a problem with using the administrative share path of c$. I suggest you go to your [share] server and make the TFSBackup folder a shared folder, and give your share the appropriate permissions.
Then you can change this:
\\[share]\c$\TFSBackup
To something like this(depending on what you name your share):
\\[share]\TFSBackup$
I know it's an old post, but just incase anyone else has issues. I had the same issue configuring backups. The following resolved it for me:
1) Open up "Services" and note the "Log On As" user for "Sql Server" and "Sql Server Agent"
2) On the folder that your backups are being saved to, go to Properties -> Security -> Edit
3) Add the users from #1, and check "Full Control", Save
Related
I am running through my disaster recovery process for TFS 2017/18 and am trying to restore the databases to the SQL server 2016 instance on the same machine as the TFS Admin tool.
I am using the TFS Administration Tool to take the full backups and also to restore them.
The issue is that after the ReportServer and ReportServerTmp DBs get restored, the TFS_Warehouse and other TFS_ databases hang while doing the restore.
The log file shows the error message: Login Failed for user 'domain\machinename$' Reason: Failed to open the explicitly specified database 'ReportServer'. [CLIENT: ]
The SQL Server has the NT Authority/Network Service account and I have also tried giving it 'domain\machinename$' as well.
I have compared it to another Virtual Machine that has a standard installation of SQL Server and TFS Server on it and I cannot see any obvious difference.
Does anyone know of a solution for this?
Regards
Based on the error message "Login Failed for user 'domain\machinename$' Reason: Failed to open the explicitly specified database 'ReportServer'. [CLIENT: ]".
Seems the related database had been dropped (database missed) or there is any service is trying to access the database which does not exist.
That means you did not restore the databases correctly or you did not really full back up the databases correctly. And when you use SSMS and manually restore each database, the related database online again, so it works.
Yes we recommend use the Scheduled Backups feature wizard to backup or restore the DBs. However you need to note below things:
You can use the backups you made of the original deployment to restore
the data from that deployment to the new server. When restoring the
data, be sure to restore all databases and the SharePoint Farm to the
same point in time. If you followed the guidance in Create a backup
schedule and plan, you used the Scheduled Backups feature to
create your backups. You will use these backups to restore your data.
If you manually configured your backups, you cannot use the Restore
wizard in Scheduled Backups to restore those databases. You must
manually restore them using the software you used to back them up.
Source : Restore the databases
Generally, we can use the SQL Server Profiler to trace the error, then debug accordingly. Within SQL Server Management Studio , choose Tools menu and then SQL Profiler with Audit Login/Logout, User Error Message events selected and check the relative entries of login fails. See below threads for details:
SQL Server Error 18456: Finding the Missing Databases
Login failed for user 'domain\username'. Reason: Failed to open the
explicitly specified database. [CLIENT: ]
UPDATE:
For the account issue, please refer to the Required permissions part in this article :Restore the databases. Just add the TFS service account as the sysadmin role, then try it again.
Required permissions
To perform these procedures, you must be a member of the following
groups or have the following permissions:
A member of the Administrators security group on the server.
Either a member of the SQL Server System Administrator security group, or your SQL Server Perform Back Up and Create Maintenance
Plan permission must be set to Allow.
A member of the sysadmin security group for the databases for Team Foundation.
A member of the Farm Administrators group.
I am trying to create scheduled backups on my TFS server.
This phase passed (no problems here):
But in next phase (When i clicked on Configure button) i got this error:
Here is the log file:
https://file.io/ZvJKLB
** I am already changed LogOn services 'Sql server', 'Job agent' to my user.
Thank you for helping!
Please try to give db_backupoperator.
if you dont have security issues the cleanest way is to give "sysamin" permission to Matan user.
Please keep in mind this error could be masking the underlying error.
During migration to Azure DevOps Server 2020.1, I received the same error and had to review the scheduling tool's log file to find that the log file for one of the databases was full.
In both the TFS 2018 configuration tool and the Azure DevOps Server 2020.1 configuration tool, there is a link to the detailed log output. Make sure you review the detailed log output before adjusting permissions on your SQL server.
*
[Info #15:34:39.634] Granting account DOMAIN\YourServiceAccount
permissions to initiate database backups of
Tfs_YourCollectionsName [Error #15:34:39.649] Exception Message:
TF30042: The log file for the database is full. Contact your Azure
DevOps Server administrator to back up the transaction log for the
database to free up some log space.
*
The fix was to perform a LOG backup to SQL Server's 'NUL' output and then configure scheduled backups:
BACKUP LOG [Tfs_YourCollectionName]
TO DISK = N'NUL' WITH NOFORMAT, NOINIT, NAME = N'Tfs_YourCollectionName-Full Database Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
GO
My server running TFS express crashed. I managed to mount the disk and extract mdf/ldf file for my TFS collection. Here is what I did next:
Built a new machine (with the same name/IP address) and installed SQL Express/TFS server express.
From SQL Server Management Studio, attached the mdf/ldf files. I can now see TFS_MyCollection as a new database.
From TFS Administrative console, clicked on "Attach Collection."
However, the new database is not being listed.
I went through a bunch of links on the Internet. https://social.msdn.microsoft.com/Forums/en-US/d949edf3-1795-448a-a1cc-39555ce87b50/tfs-2010-installation-error had a similar situation. Based on the suggestion, I had attached the database. I also looked at https://msdn.microsoft.com/en-us/library/ms404869(VS.80).aspx. However, this one talks about using backup/restore, which is not my case.
I must be missing some configuration step. Please advice. Regards.
You cant just attach a collection that was never detached.
You need to unconfigure your TFS instance (tfconfig.exe setup /uninstall:all) and then restore all of the databases.
You will need to restore each collection and the configuration DB. They are currently a set. Once you have all of the databses attached/restored you need to run the setup and "configure application tier only".
https://msdn.microsoft.com/en-us/library/ms404869.aspx
You need to follow the documentation for moving hardware. Make sure that you follow each step.
Note: You should take backups!
I am creating an msi-package of a Windows service using Wix. I want to run the service under a regular user account without administrative priviliges. For better security I want to put the files of the service in the personal user folders (such as AppData\Local\Programs\CompanyName... for binaries and AppData\Local\CompanyName... for config and data files) with the appropriate file access permissions for the user. I imagine the following scenario:
Start the msi in the per-machine context.
During the client stage of the installation ask for the user name and password.
During the server stage of the installation:
a) create the user
b) change to its context and install the program files to ProgramFilesFolder and the data files to LocalAppDataFolder
c) change back to the admin context and install and configure the service to be run under the user account
I am stuck at the step 3 b) as from what I've learned I can't change the installation context after switching to the server side of the installation. Please could you advice me on how I could achive my goal described in the first lines. In particular if I have to copy files to another user's personal folders, what would be the most reliable way to get their paths? Or maybe I am wrong and installing a service into a personal user folder is bad practice at all?
I am aware of the presence of the built-in Local Service account but would like to narrow the service context even more.
The local appdata folder is the problem. If you create a user account the user folders aren't created until the user does an interactive login, and even then in some environments it may be redirected via policy. I am unaware of any reason that local data is better (in a security sense) then the ProgramFiles folder, which is write-restricted to administrators. I'd just install the service binaries to ProgramFiles. In the UI you can collect credentials and use them when the service is installed. A problem with using external credentials is that things like Repair and sometimes patching will fail unless you have the credentials available, having saved them somewhere safe, because otherwise the property values you use will be empty on repair. If localservice works then use it.
It normally doesn't matter what privileges a service has because it usually knows what it's doing. It's only an issue if it calls unknown external code that may try to do something bad, or if it gets asked to do random things such as "run this program" or "copy this file" without doing any internal validation or having a whitelist of what it's allowed to do. So it might be useful to know if there's a specific problem you're trying to address or just following good practices.
I don't think you're being overcautious, service isolation is definitely a good goal. If you can require Win7/2008R2 or later, then you can run the service under a virtual account. There is no password required for virtual accounts, and they don't have the ability to completely wreck the machine like SYSTEM does. You should be able to use it like this:
<ServiceInstall Account="NT SERVICE\$(var.ServiceName)" Name="$(var.ServiceName)".../>
It's actually better for the service executables to be in Program Files, that way the service can't modify its own exe.
I've installed opshub on my pc that is on domain ABC. I have succesfully migrated projects from a TFS server on domain ABC to visual studio online. Now I've added a TFS server that is in domain DEF and it doesn't ask me for credentials for that server. I just get a blank collection list, I think its trying to use my current credentials from domain ABC. How can I get it to ask me for the credentials to domain DEF when trying to access that server?
User level authentication details are stored inside Team Foundation cache directory under following locations. If you have already authenticated for the TFS server then details for that server is stored inside cache directory. This won't ask you credentials again while you are doing next migration.
If you want to authenticate with the new credentials for different domain you need to clear data from the following directories.
C:\Users{User}\AppData\Local\Microsoft\Team Foundation\4.0\Cache
C:\Users{User}\AppData\Local\Microsoft\Team Foundation\5.0\Cache
Make sure original folders remains there (Cache). Just remove contents of those directories. Also make sure you close all the applications which uses TFS cache like visual studio, opshub migration utility.
See http://blogs.msdn.com/b/visualstudioalm/archive/2012/08/29/clearing-the-credentials-for-connecting-to-a-team-foundation-server.aspx for correct answer. It worked for me.