At a customer site we performed an upgrade from TFS 2010 to TFS 2013, moving from a computer in Workspace to a computer in Domain. With this operation we finally defined a DNS name for tfs so all user can access it from tfs.company.local name, instead of using machine name. After we performed the upgrade, all the user were warned of this change and we simply told them to recreate workspaces pointing to the new server.
After the upgrade some of the users were not able to create a workspace in the same location of the old workspace, Visual Studio complains because a workspace already exists in the same location.
Using tf workspaces or tf workspace commands did not solve the problem, even if we delete all workspaces associated to the user, when he try to recreate the workspace he get an error because a workspace already existed at that location.
After a brief investigation we found the reason. TFS instasnce was migrated from a workspace to a domain and some of the user in domain have the same name they have in workspace machine. Upgrading a TFS with backup and restore preserves everything, migrated TFS instance still contains old workspaces. When one of the user try to create a new workspace in the same location on Disk, TFS complains because the old workspace is still there, but if we try to delete the workspace with the tf workspaces command it failed because it uses the new users, that is different, even if the name is identical.
Whenever you have this kind of problem, the easiest solution is to download and install TFS Sidekicks, connect to TFS with an account that has administrative privilege, and verify all the workspaces that are configured in the system.
Figure 1: Tfs Sidekicks in action, showing all workspaces defined in a Project Collection
Thanks to this tools, we verified that even if we deleted old workspaces with command line, they are still there because the user, despite having the same name, are different. Deleting old workspaces from Sideckicks resolved the problem and users were able to recreate all workspaces.
If you have problems with workspaces, sidekicks is a really useful tool because it gives you a nice GUI tool to list, check, delete and manage all workspaces defined in your TFS.
Tags: TFVCNo comments
I’ve performed an upgrade from TFS2010 to TFS2013 at a customer site last week. The upgrade consisted in moving to a different machine and from a Workstation to an Active Directory Domain. The operation was simple, because the customer uses only Source Control and they want to spent minimal time in the operation, so we decided for this strategy
- Stop TFS in the old machine
- Backup and restore db in the new machine
- Upgrade and verify that everything works correctly
They do not care about user remapping, or reporting services or other stuff, they just want to do a quick migration to new version to use local workspaces new feature (introduced with TFS 2012). The do not care to remap old user to new user, they only care not to spend too much time in the upgrade.
The upgrade went smoothly, but we start facing a couple of problem. The first one is: after the migration, each team project has no user, because the machine is now joined to a domain with different users, but if we add users to a team project, they are not able to connect to team project, and they seems to have no permission. All the users that are Project collection Administrators can use TFS with no problem.
The reason is simple, in TFS2012 the concept of Teams was introduced in the product. Each Team Project can have multiple Teams and when you add users from the home page of the Team, you are actually adding people to a TFS Group that correspond to that Team. For each Team Project a default Team with the same name of the Team Project is automatically created.
Figure 1: Users added to Team through home page.
In the above picture, I’ve added two user to the BuildExperiments Team, we can verify this in the Settings page of the Team Project.
Figure 2: User added through the home page, are added to the corresponding Tfs Security Group
To understand the permission of that users, you should use the administration section of TFS, as you can see from Figure 3, BuildExperiments team has no permission associated.
Figure 3: Permission associated to the Team Group
The reason for this is: the Team is not part of the Contributors TFS Group, it can be verified from the Member Of part of group properties
Figure 4: Team group belongs only to the Project Valid User
When you create a new Team Project, the default team (with the same name of the Team Project) is automatically added to the Contributors group, it is that team that gives user the right to access the Team Project. To fix the above problem you can manually add the Team Tfs Group to the Contributors group using the Join Group button. Once the Team group is added to the Contributors group, all the people you add with web interface are now able to access the Team Project.
This behavior is the standard in TFS, if you create a new Team, the Ui suggests you to choose to add the new Team Group to an existing group to inherit permission.
Team 5: Default option for a new group is to be part of the Contributors group.
This is an optional choice, you can choose a different security group or you can choose no group, but you should then remember to explicitly add permission to the corresponding Team Group.
When people does not access TFS and you believe that they should, always double check all the groups they belong and the effective permissions associated to them.
A customer updated his TFS 2010 to 2013 in a new machine running Windows Server 2012 R2 and Sql Server 2014. Everything went fine, until after few days they started having an error whenever he tried to do a GetLatest or a Check-in or Check-out operation.
Error TF53001: The database operation was canceled by an administrator
Actually this error is not really informative, so I asked them to verify Event Viewer on the server (an operation you should always do whenever you have wrong behavior of your TFS). For each client operation that gave error they have this Event Error logged
Log Name: Application
Date: 19/02/2015 17:15:54
Event ID: 17310
Task Category: Server
A user request from the session with SPID 70 generated a fatal exception. SQL Server is terminating this session. Contact Product Support Services with the dump produced in the log directory.
This is an internal error of Sql Server, and we verified that SQL 2014 was in RTM, with no cumulative update installed. After installing latest Cumulative Update for SQL Server 2014 everything started working again. Since Cumulative Update usually address bugs in Sql Server product, it is always a good practice to keep your Sql Server up to date, and if you are experiencing strange Sql error, it could be the solution to your problems.
My RS of three mongo instances is running mongo 2.6.6 and now I want to upgrade to the latest version. Thanks to mms I can simply start the upgrade process directly from a web page, without needing to have an access to my real servers. The real good stuff is that the upgrade process is completely managed by mms for me, and the upgrade is done without stopping my Replica Set.
Since this is a test/dev environment running in my home server, my bandwidth is not so high and it is not unfrequent that one of the node finished downloading latest mongo version before the others. The nice stuff is that mms takes care of everything, and starts upgrade my secondary instances.
Figure 1: One of the server is upgrading, while the others are still running old version.
The super-nice feature is that one of the server upgraded to the new version, the others still are running the old version, and the Replica-Set version is mixed because I have node with different versions. I can connect to it with robomongo and workd as usual. At a certain moment the primary node is upgraded, now we are in a state where we have only secondary nodes, in this moment users cannot write to Replica Set:
Figure 2: Status is 2, indicating that that a member in secondary is replicating, now all node are SECONDARY
As soon as the primary node starts the new mongo process with the new version, replica set is fully operative again. The downtime is really small and you upgraded everything with few clicks, letting mms agents take care of everything.
Another big advantages of using MMS to manage your mongo deployments is the ability to automatic upgrade agents and instances. For agents you can simply open the deployment area of a group and select edit mode. If some agent is outdated, the interface will immediately warn you with an alert on the top of the page as you can see in Figure 1.
Figure 1: Mms is telling you that agents are out of date
If you choose to upgrade agents pressing the update link at the top of the pages, you should see some unpublished changes appears in the Ui.
Figure 2: Upgrading agents is a simple modification of the deploy
Remember that each modification you do through mms will be downloaded by all the agents and should be reviewed and confirmed for deploy. Pressing Review & Deploy will show pending operations:
Figure 3: Pending modification to deploy
When you press confirm and deploy, mms will confirm all modifications and the next time that the agents will poll the site, the new deploy instructions will be downloaded and applied from the various automation agents.
Upgrading automation and monitoring agents is not the only upgrade you can do from the web interface, the real killer feature is upgrading the version of mongo that your instances are running. In Figure 4 you can see that mongo mms shows my current version as red, because is not the latest one available.
Figure 4: Mms interfaces shows mongo version in red because is not the latest one available.
If you come back to edit mode you can edit any monitored instance, in this example I want to edit configuration for the entire replica set, upgrading mongo to the latest version.
Figure 5: In edit mode you can change configuration of your mongo deployment
Now you can simply edit the configuration and choose whatever version you like to install. You can install newer version, but you can also install older version if you want to rollback your environment to previous version.
Figure 6: Editing of configuration of your replica set.
Figure 7: From edit panel you can change version to whatever version you like.
Once you have done your changes and pressed Apply button, you should review your modification and confirm as for agent upgrade.
Figure 8: Changes of your replica set ready to be deployed, version will be upgraded from 2.6.2 to 2.6.5
As usual mms interface starts showing what is happening to your machines, in Figure 9 you can verify that the three machines of the replica set are downloading the new version of mongo.
Figure 9: Environment is upgrading to new version
Figure 10: Not all the machine have same speed, rs1-red is already in goal state, while the other are still installing new version
Figure 11: Replica set was upgraded to latest version, primary has changed
After a little bit, all of your machines are upgraded to the latest version. Thanks to Mongo MMS you can manage upgrade or downgrade of your instances with few mouse clicks, because automation agents will take care of all operations needed to upgrade your servers.