A 3rd party has developed some applications for us and has been using MS Team Foundation Server 2008 for their source control. My company has recently setup our TFS 2008 environment and we're trying to migrate the source code from the 3rd party developer TFS to our TFS machine. You first thought was to try the backup and restore method of migration but the only SQL Server we have available is a Standard Edition license and the 3rd party developer's SQL Server they are using for TFS is Enterprise Edition. Which means the backup and restore method will not work. So I've been trying to get the TFS to TFS Migration Tool (found on codeplex) migrate the source code. Sadly I've been having issues...
The 3rd party developer network is in its own sub-network within our company's network. And they have their own domain separate from us. So their TFS machine is on their domain, our TFS machine is in another domain, and my PC (which has VS, Team Explorer, TFS Power tools...) is connected to both networks and is trying to run the TFS to TFS Migration Tool. Alas, when I run the migration tool only a small fraction of the code gets migrated and the migration tool's log is loaded with messages...
TfsMigrationWindowsServiceHost.exe Information: 0 : TF14045: The identity <3rd party domain>\<3rd party username> is not a recognized identity.
LogicalOperationStack=Migrate
ThreadId=8
DateTime=2009-03-17T15:14:08.6591468Z
TfsMigrationWindowsServiceHost.exe Information: 0 : Unable to checkin to TFS using the identity <3rd party domain>\<3rd party username>. Converting to default credentials.
LogicalOperationStack=Migrate
ThreadId=8
DateTime=2009-03-17T15:14:08.6591468Z
TfsMigrationWindowsServiceHost.exe Information: 0 : VCSession_2009_03_17_09_59_03_627: TF10141: No files checked in: resolve the conflicts and try again.
LogicalOperationStack=Migrate
ThreadId=8
DateTime=2009-03-17T15:14:08.9247718Z
TfsMigrationWindowsServiceHost.exe Warning: 0 : TF10141: No files checked in: resolve the conflicts and try again.
LogicalOperationStack=Migrate
ThreadId=8
DateTime=2009-03-17T15:14:08.9247718Z
TfsMigrationWindowsServiceHost.exe Information: 0 : Microsoft.TeamFoundation.VersionControl.Client.CheckinException: TF10141: No files checked in: resolve the conflicts and try again.
at Microsoft.TeamFoundation.VersionControl.Client.Workspace.ReportCheckInConflictsAndThrow(Failure[] failures)
at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckInInternal(String author, PendingChange[] changes, String comment, CheckinNote checkinNote, WorkItemCheckinInfo[] workItemChanges, PolicyOverrideInfo policyOverride, CheckinOptions checkinOptions)
at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn(PendingChange[] changes, String author, String comment, CheckinNote checkinNote, WorkItemCheckinInfo[] workItemChanges, PolicyOverrideInfo policyOverride, CheckinOptions checkinOptions)
at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn(PendingChange[] changes, String author, String comment, CheckinNote checkinNote, WorkItemCheckinInfo[] workItemChanges, PolicyOverrideInfo policyOverride)
at Microsoft.TeamFoundation.VersionControl.Client.Workspace.CheckIn(PendingChange[] changes, String comment, CheckinNote checkinNote, WorkItemCheckinInfo[] workItemChanges, PolicyOverrideInfo policyOverride)
at Microsoft.TeamFoundation.Migration.Toolkit.VC.SourceToTfsMigrationEngine.Checkin(ChangeGrouping group, Int32& changesetId)
at Microsoft.TeamFoundation.Migration.Toolkit.VC.SourceToTfsMigrationEngine.ProcessChangeGroup(ChangeGrouping group)
at Microsoft.Vsts.Rangers.Migration.TfsToTfs.TfsToTfsMigrationEngine.ProcessChangeGroup(ChangeGrouping group)
LogicalOperationStack=Migrate
ThreadId=8
DateTime=2009-03-17T15:14:08.9403968Z
The above message can be found 100s of times in the log. I am guessing this 'identity' issue is the reason why the vast majority of files are not migrated over. But then again I would have thought ALL files would have had this problem...including the few that were migrated over.
I've found very little specific information about 'TF14045' and 'TF10141'. I get the impression that the problem is due to the fact that file checkins on the 3rd party TFS environment are associated with users specific to that domain and are not found in our domain. So...
Does anyone who is familiar with the TFS to TFS Migration Tool have any idea what the problem might be?
Can anyone think of a way around this situation so that the new TFS machine doesn't freak out when users of the other domain are linked to files being migrated to the new environment? I did try adding the problem '<3rd party domain>\<3rd party username>' to the new TFS environment but TFS couldn't find that user and wouldn't add them.
Better yet...if anyone knows how I'd love to know how to do the backup and restore migration method using different SQL Server versions.
i dont know if this helps but you can try setting up inter domain trust , so you can login with users from both domains.
I solved my issue by solving the problem manually in the workspace and then providing the check-in number as the "Source Version" to resolve the conflict...
TFS Integration Tools – Issue: TF10141 No Files checked in as a result of a TFS check-in failure
Related
For some time, I get an error when I try to log into my Microsoft account from Visual Studio for my Azure subscription.
My Microsoft account is associated to : Outlook.com (obviously), Office 365, Azure and a Windows Developer.
I ignored this message until now, because I could connect to my database, my websites functioning, etc.
But now I need to publish an application in the Windows Store. When I try to generate my Windows app packages, I found the same error:
We could not refresh the credentials for the account
AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials.
Trace ID: eaf34263-377e-41d3-8f72-177827315914
Correlation ID: 15bbcfe8-8bc9-4a83-aa02-288a54e50dd5
Timestamp: 2016-09-19 11:27:20Z
I have already try to clean up cookies, temporary files, another Windows developer account, ...
UPDATES
I have try to download Azure AD Application Proxy Connector.
I had this same problem again on Visual Studio 2017 (15.1).
Solution found:
You have to go to REGEDIT.
Navigate to "Computer\HKEY_CURRENT_USER\Software\Microsoft\VSCommon\ConnectedUser"
And empty all the values, except EnableAzureRMIdentity (change to true if isn't) :
To :
It seems that you’re trying to sign in through a Microsoft account and not a domain that is part of the organization ID of the directory you are trying to access.
So please make sure that the admin is part of the same domain name as the tenant domain.
For example, if your Azure AD domain is contoso.com, the admin should be admin#contoso.com.
You could refer to Troubleshoot Application Proxy.
Moreover, this thread might be helpful to you. Please also try the answer provided by Rich.
I followed some of the advice for this error, including modifying my registry key, however the error changed. And it seems that the #Andrés Talavera is also using a sovereign cloud like I am.
I deleted my Environment Picker JSON file and that is when I got this error when I restart Visual Studio.
After deleting the JSON file, located here: %localappdata%\.IdentityService\AadConfigurations\AadProvider.Configuration.json, I restarted VS17 and I got this error. The JSON file seemed to reappear after the restart. The next time, after I deleted the Registry Key, and removed the JSON file again, SSO worked great.
Note: It seems to be associated to the Environment Picker and pointing to the Sovereign cloud AAD.
I would like to create a new installation of TFS 2013 on a new server.
I made my research and learnt that the migration process as it is described on this link below carries some risks:
TFS Migration Manual:
https://msdn.microsoft.com/en-us/library/ms404869.aspx
Risks:
http://blogs.msmvps.com/p3net/2014/04/12/tfs-upgrade-nightmares/
I have a plan to avoid using the TFS Migration manual above, instead; I would instead check all of my projects out (about 20) and then re-create them on the new TFS and check them in again.
However, we have work-items, users, workspaces and other agile information which I have created for my projects, and which I still require to be on the new installation.
I was wondering whether the following works (again without risks and hassle, as time is scarce):
Back up the TFS Databases from the old installation, and restore them into the new installation or simply import the data from old to new using SQL Server's Data Import Tool.
I am particularly referring to these databases, which TFS has:
Tfs_Configuration; Tfs_DefaultCollection; Tfs_Warehouse.
I found these databases on the SQL Server instance which TFS uses.
Also, this approach works easier without having to obstruct the team, as the Data Base Resotation can occur after hours..
Now, will this plan work?
No, your plan will not work and will leave your TFS in an unsupported state.
You need to follow a combination of the Upgrade and "changing environment" workflow.
1) Restore all TFS databases (tfs_*) to tye new environment
2) Install TFS 2015
3) Configure and select Upgrade Wizard - when running make sure you have all the new server names
4) (optional) ChangeServerID - if this is a practice run you should then immediately:
4.1) I unconfigure the application tier with "tfsconfig exe setup /uninstall:all"
4.2) run the ChangeServerID command
4.3) reconfigure tfs and run the "app tier only" wizard
Simples....
Note: You need to change the server ID if this is a test/practice instance as each server gets a unique ID. When clients first connect to the new server they will "upgrade/migrate" the users data across. You don't want that happening for a trial...so change the ID...
WARNING: If you manipulate the data in the TFS server in any way that is not done by the TFS Product Team tools you will turn your instance to crap. Do not ever edit, or cause to edit, the data in the operational store.
I am writing a "framework" of SQL Server (targeting 2008R2 and 2012) stored procedures and common/reference tables. Each SSDT/Date-tier project represents a different component (can be within the same database) within this framework (e.g., MasterDBExtensions project has stored procedure extensions/add ons within the Master Database, SQLServerAgentExtensions (msdb), etc).
I developed a farily strict security model heavily based on Schema, database roles, and certificates.
My issue is how do I "share"/copied these certificates between the active project and the referenced projects so that when I publish the active project to SQL Server the certificates are properly copied, etc. (btw I need to share/copy the certificates for cross-database object access so that I do not need to turn the Trustworthy flag on, Service Broker, and also for linked server access).
Just for clarification I have some TSQL Code that represents what I mean:
use [DatabaseA]
Create Certificate [MyCertFromA] ...
Backup Certificate [MyCertFromA] to File = 'MyCertFromA.cert'
use [DatabaseB]
Create Certificate [MyCertFromA] from File = 'MyCertFromA.cert'
SSDT/Data-tier will NOT allow me to place the Backup and Create/From statement (I get the "This statement is not recognized in this context"). If I move the Backup Certificate to a Pre/Post Script I run into issues with file permisions and other issues (e.g., Certificate NOT found). Besides the Pre/Post scripts do not run if I use the project as a database reference in other projects.
So... What am I doing wrong or does anyone have any suggests around these issues?
Thanks!
Enviroment: SQL Server 2012 (I also target SQL Server 2008R2), MSVS 2010, SqlServer Data Tools Dec. 2012, SQL Sever Data-Tier Application Framework May 2013, C# 4.0
Looks like this has been answered somewhat by CTP4 Certficate issue - sometimes server, sometimes database scoped
I currently have a TFS 2010 Server running on SERVER-1. On my client (MY-CLIENT) I have VS2010 running and have a workspace associating SERVER-1 with \MY-CLIENT\Development. All is good.
I was playing around with setting up a different instance of TFS on SERVER-2. On my client, I deleted the original SERVER-1 workspace and created a new workspace associating SERVER-2 with \MY-CLIENT\Development. All is good.
Having finished my experiments with TFS on SERVER-2, I re-imaged the machine (deleting the TFS Server on SERVER-2).
I then went back to my client machine, reconnected to TFS on SERVER-1 and attempted to remap source control to my Development folder. However, am now receiving the error "The path \MY-CLIENT\Development is already mapped in workspace MY-CLIENT;SERVER-2\Steve." Now I have a problem.
So, I gather from this that I should have first deleted the SERVER-2 workspace BEFORE re-imaging the machine. Unfortunately, I did not do that.
Poking around in some forums, I realize that I can use a command line tool to perhaps delete it:
tf workspace /delete MY-CLIENT;SERVER-2\Steve
However, when I run this, I get a message indicating that "Team Foundation services are not available from server http://SERVER-2:8080/tfs/development."
So the question, then, is how do I force deletion of the SERVER-2 workspace on my client so that I can re-create my old SERVER-1 workspace?
The working folder mappings for all the local workspaces is stored in the version control cache file. This allows you to bootstrap TFS clients, allowing them to locate the server information for a given local folder. In addition, it will provide the information for this test you're seeing, that prevents a local folder from being mapped to two different servers.
In order to clean this up (without trying to connect to the server), you can use the tf workspaces command (note the pluralization - the workspaces command operates on the list of workspaces, the workspace command operates on a workspace and generally requires connectivity to the server that workspace is located on.
To delete all workspaces for your deleted project collection, you can do:
tf workspaces /remove:* /collection:http://server-2:8080/tfs/DefaultCollection
(Obviously replacing the project collection URI with the URI for your deleted server.)
I had exactly the same issue: After moving TFS server to another machine, I couldn't map to a local folder in VS2012 on the old machine because it was still associated with an old Workspace that TFS denied all existence of. After many hours (and days) searching Google and trying different things, none of which worked (including all the "tf" commands, deleting the local cache etc), this is how I eventually solved it:
Edit the actual TFS collection database on the TFS server using SQL Management Studio Express (e.g. "Tfs_DefaultCollection")
Look for the "dbo.tbl_Workspace" table and edit it
You should see your "ghost" workspace(s) in here
Delete the rows
All is right in the world
The workspaceowner parameter on the delete command is optional. Can you issue the delete without that parameter, or will that damage another MY-CLIENT workspace?
We have a an ASP NET MVC website solution which only one out of three devs on the team is able to publish to the live server. When I, and another colleague, attempt to publish the site from VS 2010, the output window will display an error:
Unable to create the Web site
'\blah'. The path '\blah' does not
exist or you do not have access. The
specified path is invalid.
This points to a logon issue which my account, but the developer who can publish the site is a member of all the same user groups as me. As a long-shot, we gave Everyone full access to the folder, but this did not resolve the problem.
Can anyone suggest a more detailed way to try and figure out why we cannot publish the site? There must be a permission set somewhere that is allowing my colleague to publish the site from Visual Studio.
I had this problem and racked my brain trying to resolve it so I wouldn't have to copy the publish files to a remote server manually. I spent a great deal of time actively trying to get this to work.
Here's how I solved the problem: I went to File>Open in Visual Studio 2010 Express and navigated to the remote server (\\255.255.255.255\folder1\folder2\folder3 and so on). Right away I was challenged for a User Name an Password. I entered the credentials for the REMOTE server, checked the box to 'Remember my credentials'. I immediately tried to publish and voilá - it worked like a charm.
I hope this saves a lot of people a lot of time.
I had this issue - certain members of our team were able to publish directly from VS2010, whereas for some reason I was always getting permission denied errors, even though we were all able to connect to the server we were trying to deploy to. I fixed it in the following way:
Go to "Server Explorer".
Right click "Servers" and go to "Add server..."
Type in the name of the server you are trying to connect to, and then click on "Connect using a different user name..." - put the credentials for logging into the server in here.
Click OK and wait for it to add the server.
Now try and publish to that server and it should be ok...
Not sure why I needed to do this and others were able to deploy without adding the server in this way... remains unexplained.
According to the comments below:
You may need to restart Visual Studio in order for this to take effect.
This should also work for newer versions of Visual Studio
Faced the same problem today. In my situation I had to close VS2010 and open it NOT as an admin and it worked without any problems.
This got me for a long time...Go to Project - Properties and select the Package/Publish Web tab. Under the header "Web Deployment Package Settings", there's a ellipsis button that you can use to map to the location you want to publish. You will be asked for your credentials during that process.
Are you using web deploy (right click and choose Publish)?
Have you tried copying the ProjectName.Publish.xml file from the one machine where you can publish to the other two machines? The login credentials for publishing are saved in this file.
In IIS can you check to see that all users/groups are listed under Management Service Delegation in IIS Manager? It is listed under the Server node in IIS. Alternatively you can give all administrators access by clicking on Edit Features from the side-menu and checking Allow Administrators to bypass rules.
You could also check under IIS Manager Permissions for the individual site to see if the person that can publish is listed under there and you are not.
I just recently setup MSDeploy access on my server and found the following two tutorials helpful:
http://william.jerla.me/post/2010/03/20/Configuring-MSDeploy-in-IIS-7.aspx
http://code-inside.de/blog-in/2011/04/03/howto-setup-of-webdeploy-msdeploy/
I have also found that mapping a drive to the UNC location can be a work around.
#soupy1976's solution has also worked for me.
I can not explain why one day it will work and one day it won't
Frustrating....