It seems that security setup is a bit of a nightmare with TFS --- particularily as it relates to TFS versus SharePoint versus Reporting Services.
Does anybody know of a tool that can validate the security setup --- because as it stands now, people can't create projects, because something is wonky with SharePoint --- yet all the farm administrators and site collection administrators seem to be set correctly.
One thing to try is to create a new Team Project logged in to the TFS server (AT) using the account that you used to install TFS (tfssetup).
If that still doesn't work then sounds like you might possibly have your Sharepoint Admin URL set incorrectly in TFS.
One thing you might want to try if the TFS Best Practices Analyzer which comes with the TFS 2008 Power Tools and will point out common configuration issues.
You might also want to try the tfsadminutil ConfigureConnections /View command to see if you can see anything there.
Good luck,
Martin.
Related
I am working with a customer which have SharePoint 2013 dev, test and prod environments sitting in a datacentre. We are moving the datacentre which means their SharePoint 2013 needs to be moved as is. They have 1 heavly custom build application on top of SharePoint which needs to be moved. I need confirmation, process suggestion on the migration part.
I install SharePoint 2013 like for like in new environment.
Option 1
I take backup for their databases and restore them on new SQL Server. Use Mount-SPContentDatabase to mount database and test if everything is working as expected
Option 2
Recreate web application, site collections, activate custom features, timer job and migrate content.
I personally think that option 1 is more applicable but need input and suggestions. Any road blockers or gotcha are also encouraged.
Thanks for sharing your experience
As its a same version migration it wont be much of an issue but go with option 1.
Re Creating the whole farm is so hard specially if you decide to deploy each and every component.
I've migrations to same version and these are the steps that i follow.
Create a checklist of all solutions and features (WSP etc).
The check list should have the same services that are running in the farm as well.
Install SharePoint in the new farm and update to the same version as the existing farm , having same version will reduce a lot of
problems.
Create the service applications just like the existing farm.
Restore the service application databases (MetaData, UserProfile etc)
Create the web application and restore the content database
Deploy the custom solutions
Confirm that everything in your checklist is deployed and working fine
Fix errors if there are any
This is the flow that i follow and so far i've been successful.
Good Luck
We have a company SharePoint site that we paid a company to configure and setup for us. We are slowly taking over more and more of the administration of this site. We would like to setup a test environment so we can make changes with out affecting daily business.
How can we take what they have already installed, deployed, and configured and make a copy of it?
I know we can backup the database, but what about the stuff the downloaded and deployed into the system?
None of what they installed are paid applications from what i can tell. They look like the base applications from the Microsoft SharePoint site like Case Management, Knowledge Base, and a few others.
Thanks
You should take an inventory of the installed solutions, you can see that in the list of solutions under central administration. Then try to identity 3rd party solutions and get the WSP files (I bet they are stored in a folder on your server :))
Set up a new environment, make sure to install exactly the same version, including any service packs and/or hotfixes. You can get that list when you search for the version number in Google (the version number is usually seen in the Site Administration page).
After that, install your custom solutions and attach the content database, this should be it.
Is there a way to export all of TFS 2008 Groups and Permissions for an Audit?
I looked at the TFS Permissions Manager mentioned in another answer and couldn't easily figure out how to use this for an audit of user permissions. That said I looked around and found a few other possible tools to help in this process:
Team Foundation Server Administration Tool - This can be used to produce a list of TFS groups, users & permissions on a per project basis. The utility uses a grid control to display the results and this can easily be copied and pasted into Excel, etc.
TFS Project Audit - This tool generates output in an indented text format. It too works on a per project basis however it lists the output grouped by TFS role.
I think both of the options I mention are more recently maintained than the TFS Permission Manager at the time of this writing. Also, keep in mind that for purposes of a security audit I believe that the local & domain administrators groups in Windows Server have the ability to override any of the TFS permissions (at least with TFS 2008).
I'm the guy who wrote TFS Project Audit and I'd like to clarify a few things about my tool. First, it works on a project basis for TFS 2008 or a collection basis for 2010. It can report on a specific collection or all collections on a TFS server. These are enhancements I made in the newest version, released only a few days ago. Also, the output can be restricted to a specific group, Project Administrators, for example, across a project, collection, or the entire server.
I am always soliciting but rarely receiving feedback on this pet project of mine, so please feel free to leave suggestions for future releases! I have plenty of ideas in mind but it would help to know where my time is best spent, because this projectis hardly all I do with my days.
To prove it is really me, I'll give Saul a shout at tfsprojects.codeplex.com. Thanks a lot Saul!
Have you looked at this?
http://blogs.microsoft.co.il/blogs/srlteam/archive/2006/11/27/TFS-Permission-Manager-1.0-is-Finally-out.aspx
I have created a new SharePoint 2007 MOSS Intranet. Our admin people are purchasing backup/restore software and I will eventually have to verify a restore of the farm backup they create. Has anyone got some suggestions on a best practice for this? Ours is a small 2-server farm built with VMWare VMs on SAN. How will I know that the restored version is a duplicate of the original in every way and what should I look out for?
In answer to the remarks:
There's no checklist. The problem is the dynamic nature of SharePoint. Team Sites come and go, as do documents and libraries. Who's to say one of your users didn't delete a document library and then you think after a restore something is missing.
I think the best bet would be to require your users to do a quick scan after a restore, see if they miss anything major, like sites or libraries that are supposed to be there. You yourself could have a "homemade" checklist that you follow to check if all major features deployed by you (features, timerjobs etc.) are still there.
Or are they two distinct applications that are not related?
They are very different, although some people push the list of source control commits or latest files (head) to their team wiki (which could be SharePoint)
SourceSafe and SharePoint have no connection, however Team Foundation Server and SharePoint do have a connection. For each new Team Project you create Team Foundation Server will create a project site that is a SharePoint (WSS) site. You can store whatever project information you would like there, as well as look at various statistics and reports related to your project from the site. The site can be useful for non-developers (anyone without Visual Studio and Team Explorer) to be able to view information about the project such as work items, reports, build statistics, etc.
They are unrelated as Source Safe was created by a different company that MS acquired. Team foundation server and SharePoint is a different story. I believe that Team Foundation Server is an extension WSS.
I believe they are unrelated but both use SQL Server as their backend.