Our IT decided to migrate AD to a new domain. Now, those who did migrate their accounts, facing an issue - they've lost code reviews and shelvesets. They didn't really lost it. It is still accessible via "Find Shelvesets" and enter olddomain\user. But "My Work" is now disconnected. And even opening the "My Work" query and modifying a user name to the old user, still no success.
To clarify - only users being moved to new domain, not the TFS server
Did anyone have done something like this and any recommendations, workarounds?
They unfortunately did the domain move incorrectly. If done correctly, the data will carry over to the new user. Unfortunately there is no proper fix after messing this up as TFS now has 2 records with a unique identifier. These records can' be removed or merged.
You should be able to do the following in a script:
create a workspace (tf vc workspace)
map the project folder (tf vc map)
get latest (tf vc get)
query all shelvesets of your old user (tf vc shevesets)
in a loop
Unshelve shelfset (tf vc unshelve)
Shelve a new one under your current user (tf vc shelve)
Undo pending changes (tf vc undo)
A number of these commands support a /format:xml argument, making it easy to call them in a PowerShell script and extracting the data for the next steps.
I don't think my-work will restore the associated work items and all. My Work has been removed from recent versions of Visual Studio, so you could use this as a good time to get used to that.
Other things that may have gone missing:
"My Queries" under work items
My Capacity
Work item associations
Pending changes in workspaces
The correct way to do TFS domain migrations is to suspend the server, do the account migration, then run tfsconfig identities:
{Server install path}\Tools>TfsConfig.exe identities /change /fromdomain:old /todomain:new /account:old /toaccount:new
But this can only be done as long as TFS hasn't yet synced the new identity into the database. This may help future issues as they move new users over.
Related
I updated the name + icon of my Bot Framework Bot. In Teams I don't see a way to get it updated.. I remember having to remove some cache folders in program files manually but wonder whether there's an easier way (+ bot in Teams from Web has little to do with my local cach and also that one doesnt refresh).
How do I refresh my bot name + icon in Teams deskop + web?
Unfortunately, MS Teams does not provide an easy way to 'refresh' a bot icon, but it is doable. The first thing is to realize that there are two sources for the icon that come into play: 1) From your bot settings in Azure, and 2) the app manifest used for loading a custom app. (I'm not able to test installing via the Teams App store, however I would guess it would yield similar results to loading a custom app.)
In testing, each source appears to effect a different part of the Teams app. If you update your bot icon in the bot settings in Azure, this updates the conversation bot icon and the bot icon that displays when you type in a contact name. The does not update the bot's 'profile' and/or app image. These must be updated from a new manifest.
The user can uninstall and reinstall the custom loaded app (bot), however simply installing the updated manifest on top of the current bot without uninstalling appears to work just fine.
Lastly, in both cases, the user will need to clear out their Team's cache files. The following instructions explain how this can easily be done on a Windows 10 machine (original posting located here). Please forgive the formatting...markdown isn't playing nice with my letters and bullets.
If you want to clear MS Teams cache, you could refer to the following ways:
1. Fully exit the Microsoft Teams desktop client. To do this, either right click Teams from the Icon Tray and select ‘Quit’, or run Task Manager and fully kill the process.
2. Go to File Explorer, and type in %appdata%\Microsoft\teams.
3. Once in the directory, you’ll see a few of the following folders:
a. From within ‘Application Cache’, go to Cache and delete any of the files in the Cache location.
* %appdata%\Microsoft\teams\application cache\cache
b. From within ‘Blob_storage’, delete any files that are located in here if any.
* %appdata%\Microsoft\teams\blob_storage
c. From within ‘Cache’, delete all files.
* %appdata%\Microsoft\teams\Cache
d. From within ‘databases’, delete all files.
* %appdata%\Microsoft\teams\databases
e. From within ‘GPUCache’, delete all files.
* %appdata%\Microsoft\teams\GPUcache
f. From within ‘IndexedDB’, delete the .db file
* %appdata%\Microsoft\teams\IndexedDB
g. From within ‘Local Storage’, delete all files.
* %appdata%\Microsoft\teams\Local Storage
h. Lastly, from within ‘tmp’, delete any file.
* %appdata%\Microsoft\teams\tmp
4. Once finally done clearing, you can now restart Teams from your local desktop and all cache will be cleared from the desktop app.
In this way, I have been able to update the bot icon. Not a terrible process, but certainly not a friendly user experience.
Hope of help!
Locally installed TFS2013, VS2015 and VS2013 using SharePoint services.
So far the development system is kind of OK, meaning I can create a collection, create a team project within a collection, add a new solution to that, run it, do a Check In and the SharePoint site shows the project code, etc. I can also create work items at the SharePoint site and from within Visual Studio.
But I'm having difficulty understanding how the user accounts are interacting. On my development workstation I logged in with a normal domain account. But I do not see work items assigned to that user name. I only see work items if they are assigned to the system Admin account.
I would have expected VS would be operating under the user account that I logged into Win10 with, but it seems to be operating as though VS is logged in as the system Admin.
Why is that? Is there a place where VS sets data that tells TFS what user name it is operating under? And, of course, I may be asking the wrong question because I don't understand the problem, but this is how it appears.
Added after initial post for clarity
This panel shot shows where the Work Items were not showing up for the user under Available Work Items. Because of the issue identified in the answer below, only work items assigned to Admin were present. But after clearing the cached credentials the work items displayed correctly according to the proper account, no longer acting as Admin.
This may due to the VS had cached your system Admin account.
The simplest way is to delete the related credentials which stored in control panel > Credential Manager> Windows Credentials
Then reopen the VS and try to connect to TFS server. It will pops up a credential window, just type your login domain account.
I have a quite weird problem here with UCM-ClearCase.
A user tried to deliver from his dev-stream to the int-stream of the project. For some reason he decided that he needed to cancel the delivery and executed "deliver -cancel". According to him this did not work the first time (although he does not remember the error message) but the second time he issued the command the delivery was actually canceled.
The problem now is that he has a checkout in his int-view (!) that does not have an activity attached to it. The activity of the delivery was deleted (obviously during the cancellation of the delivery). If he tries to undo the checkout in the int-stream (by using "unco") ClearCase outputs a warning that he needs to set an activity and a view context in order to undo the checkout. Setting some activity (and a view context) is no good, the same error message appears.
EDIT:
The exact error message given by ClearCase is:
cleartool: Error: To operate on UCM branch, must be set to an activity and a UCM view.
cleartool: Error: Unable to cancel checkout for "PathToFolder".
The checked out element is only a folder and no other elements (neither files nor folders) are checked out
END_OF_EDIT
Creating a new activity in order to attach it to the checkout did not help either as I did not find a command to attach an activity to a already checked out folder.
According to IBM we could remove the view and all its references and then re-create it which should solve the issue of the checkout.
I am kind of hesitant to do so without being sure that there is no other way to handle the situation (especially as the above-mentioned link states that there might be cases when removing the view does not really help). Is anyone aware of a different solution for this kind of situation?
Best Regards
I confirm that to remove all checkouts associated with a specific vob and view is
cleartool rmview -force -uuid (uuid_of_the_view) -vob \aVob
See "unable to perform delivery on clearcase because of checked out file in snapshot view?"
Simply make sure the user has no other checked out files.
I want to give access to all employees of the company to access the TFS server, but i just want to give them the right to view/edit and created Bugs, just Bugs, no access whatsoever to view tasks, source code or anything else, just bugs, how is this possible?
As an alternate option you could control all work item access on the Project-Area level.
TFS projects have "Areas". They can be setup to be what ever you want to call them. Many people organize these by feature or application "part".
You could restrict access to all working areas but leave access open to a "Triage" or "Bug Reporting" area. (Or if you just want to shut people out entirely just remove them from the root "Area" node.)
To do this right click on your project in Team Explorer and select Team Project Settings. From the sub menu select Areas and Iterations.
Set up your areas something like this:
Select the Development area then click the Security button in the bottom left corner.
In the resulting dialog you can setup permissions as needed to restrict view and edit access to work items in that area. Then when your developers make work items (tasks etc) make sure they set the area correctly. This will limit access to those work items.
Since you leave the "Bug Reporting" area open, users can still add bugs (or sadly Tasks) to that Area. Once you plan on working on the bug you can move it into the Development area.
This works, but has several drawbacks:
Users can't see the status of the Bug they reported once it goes into development. A Sharepoint dashboard report could help with allowing viewing of that status.
Users can still make non-bug work items. This means they can make tasks and such if they choose to.
An alternative is the use the Work Item Only View of TFS. This is a tfs portal that is setup automatically with TFS 2010 and can be installed in TFS 2008. It allows users to enter work items and see work items that they entered. But that is all. This is a fairly limited view, but it may work for you. (But remember, a person can only view work items that were created by them.)
The main benefit is that you don't have to purchase a CAL license for users to use the Work Item Only View (WIOV). Depending on how many users you are planning to give access to, that can save you a lot of money.
Here is a link about that: http://msdn.microsoft.com/en-us/library/cc668124.aspx
As a side note, both WIOV and the Area security would work fine together if you want.
EDIT: After re-reading your comment I think you might have been asking how to restrict users from accessing source. To do that open the Source Control Explorer and right click on a project or the root node and select properties. From there you select the security tab and you can deny access to source control from there.
This can be done for creation, but not viewing (to my knowledge). However, this is a lot of work. To do it you have to edit the work item type templates.
Basically you would edit the non-Bug templates so that only a specific group of people have rights to all the fields. You would also have to restrict transitions (i.e. move the non-bug work item to "Created" (or what ever your "new" work item state is).
This is a lot of editing, but it could be done.
This blog post gives the basic idea:
http://social.msdn.microsoft.com/forums/en-US/tfsadmin/thread/178bc809-0035-45ee-9e0a-65ac412186f1/
and this is the docs for the Not parameter to deny transition permissions:
http://msdn.microsoft.com/en-us/library/aa337653.aspx
And lastly, here is the ValidUser docs:
http://msdn.microsoft.com/en-us/library/dd997577.aspx
We have two Application Tier servers, one is used by the client only, so I edited the JS source for TFS web access to not allow adding anything other than Bugs, Change Requests or Issues.
In (TFS Deploy folder)\Application Tier\Web Access\Web\Resources\Scripts, you can edit the DocumentService.js file:
//Opens new workitem editor with specified workitem type.
//workItemType: WorkItem type name.
DocumentService.newWorkItem = function(workItemType, tfsLocator)
{
if (JsUtility.stringIsNullOrEmpty(workItemType))
throw "Unspecified WorkItem Type Name.";
if (workItemType != 'Bug' && workItemType != 'Change Request' && workItemType != 'Issue') {
alert('Only Bugs, Change Requests and Issues can be created from this site');
}
else {
var _url = this.createUrl(CommonUrls.WorkItemEditor, { wit: workItemType }, tfsLocator);
return WindowHelpers.openWindow(_url, "_blank"); }
}
I have a very simple VS2005 deployment project that aims to install for all users on a PC.
All the application files are written to %Program Files%\MyProg. A shortcut is created in the start menu and the startup folder. No registry settings or anything else are created. I have set
'InstallAllUsers' to true.
The created MSI runs fine and installs the software. It works without any problems when running under the user account from which it was installed.
When logging in as another user, the start menu and startup icons are present. It attempts to launch the application however an installation window pops up and states that 'the feature you are trying to use is on a network resource that is unavailable.' The installer will only proceed if pointed to the original MSI file.
Why does this happen? I want my application to be installed completely for all users when it is installed by a single user.
edit: Solution
I was getting similar event log messages as shown on this page. In my case it turned out to be as simple as ensuring that the User's Program Menu had its 'AlwaysCreate' attribute turned to false. If it was true, windows would try and recreate the folder when a new user logged in. This somehow required the invocation of the installer and thus resulted in the 'please insert the installation media' prompts.
It is actually kind of hard to say without some more information. I would recommend checking on the rights in the installed folder (seeing if only the one who installed it has rights) and also checking the file list for the directory (to make sure VS didn't automatically place some files in the user profile). Let me know what comes out from those two steps and we can try to keep digging if that didn't shed any light on it.
Keep in mind chances are this is most def not specific to Visual Studio, look at this MS support article here where the same message is coming back for office.
I know this is an old post but I thought I'd add another cause and solution in case the above didn't work for you.
There is a bug in VS Setup and Deployment Projects which results in registry values being entered into HKCU instead of HKLM irrespective of the InstallAllUsers property being set to true.
You must use Orca msi editor to change the registry root for "DesktopFolder" and "ProgramMenuFolder" from either 1 or 2 to -1. The issue cannot be resolved via VS.
http://www.qa.downappz.com/questions/vs-2010-deploys-per-user-features-during-install-which-require-access-to-install-media.html