locked
Good God what a mess!!!! RRS feed

  • Question

  • well it's getting better but the install / setup process for TFS is still way to hard IMHO!

    for example the notes in beta 3 say
    "after installing Share point and Report services test to see that they are both working"

    but when I did the steps as given SSRS web UI fails to work...

    then I found a blog post that says to go into the admin of SPPS and exclude the report server folders... ok now the test works...

    so start to install the main TFS and I get an error telling me that SPPS is not configured right!!!!!!

    dang it just build an installer that loads and configures all the bits.....

    Hey I know it's "Beta" but please Tongue Tied
    Monday, October 10, 2005 8:07 PM

Answers

  • Gregory,

    Really appreciate your taking the time to provide us with this feedback

    I'm will be forwarding this around internally and look to see how we might improve the setup experience

    marc
    Tuesday, October 11, 2005 6:00 PM
  • Denny,

    It looks like you are installing Beta 2 and not Beta 3

    1. You can absolutely use workgroup w/ Beta 3, but only on a 1 box deployment.
    2. AD/AM is no longer required

    You can use Terminal Server to access TFS ... but not what you'll want for source control.  Many folks internally at MSFT use TS to access the system.

    For configuration, you only need one TFS server and you can have multiple projects running on it.  You can also do 1 project, like we do for TFS, but it has many sub areas for each of the features.  This includes ASP.NET pieces, NT Services, Web Services, SQL, etc.

    Does that help?

    marc
    Sunday, October 16, 2005 11:20 PM

All replies

  • I agree.  It took about two weeks of working on and off and several reinstalls to get it working for me due to a lot of contradictory information.

    Monday, October 10, 2005 10:32 PM
  • I'd be curious to get some more information on the kinds of issues you saw.

    We know that the docs went out and we uncovered some additional 'items' that needed to be addressed. Rob & Co are busy getting everything to line up.

    But doesn't mean we caught it all, so any information that can help us make it better is appreciated.

    - marc
    Marc Kuperstein [MSFT]
    Tuesday, October 11, 2005 1:47 AM
  • Keep in mind that my installation was done on a domain controller.  I wanted to test in that scenario because when the release is actually made, there is a possibility that I may run on a DC.  There are some special situations that must be handled if you are going to install on a DC, and none of these were covered in the documentation.  I think you should consider this a real possibility and devote some documentation to this installation.

    Also, consider that some of these steps may have not been the Microsoft recommended approach to getting the installation to work.  However, they were pieced together from reading other articles in the newsgroup and my debugging.

    I want to state that these are most of the issues that I had getting the system just up and running.  I'm still not able to use the system in a desired manner because of failures in VSSConverter.  Also problems with TFSDeleteProject and the fact that new project creation fails about 20% of the time has cause me problems.

    1) Before installing IIS, you should be reminded in the documentation that you must promote to a DC first.  I acknowledge that was probably my fault and did cost me some time, but a reminder in the documentation would have prevented this incident.

    2) Problems getting directory permissions set properly for SharePoint services.  The TFSSERVICE account did not have permissions to %WinDir%\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files.  This caused problems with SharePoint because it could not create files as required.  The installation process should have done this itself or explicit instructions should be present so we know this is a requirement.  This took significant time to diagnose, partially because I figured something had to have gone wrong in the installation for this not to be automatically handled.  I wasted much time on this.  Probably restarted the entire process from ghosted sysprep'ed OS image at least 10 times.

    3) Had to manually add the Log on Locally privilege for TFSSERVICE and TFSREPORTS for the server.  I'm running a single tier approach at this time.  Again, should be handled automatically for DC in installation, or explicit instructions in the documentation need to be provided.

    4) The bug I reported in using Active Directory groups for permissions in VSTF where a user account's primary group is the same group as the group assigned in VSTF caused me to devote time to determine why my accounts were not getting the desired permissions.

    When I stated that some of the steps were in direct contradiction to the documentation, I was thinking that I had to change the TFSSERVICE account to an administrative account.  I actually had read that some others had done this to solve the directory permissions problem, even though it did not work for me.  So at one time, this account was a member of the administrators group.  However, after looking back, I now see that once I changed the permissions on the folder, I removed the administrative membership of the TFSSERVICE account.  I apologize for that misquote.

    Nevertheless, due to deficiencies in the installer or undocumented critical steps, the time it took to get the system up and running was much more than one can typically devote.

    Tuesday, October 11, 2005 1:42 PM
  • Here's the issues I had (I'm reading this from some notes I made when I installed TFS a couple of weeks back, so hope I haven't missed anything.):
    (1) I had to issue this command:
      stsadm -o extendvs -url http://tfsservername -ownerlogin DOMAIN\TFSService -owneremail tfs@my.fully.qualified.domain.name
    (2) I also had to put an entry in to the table STS_CONFIG.dbo.VirtualServers for the server name tfsservername above, because there were no entries in this table at all. The LastModified, LastModifiedUser, LastModifiedServer, Status, and Properties columns I cribbed from the data in the STS_CONFIG.dbo.Globals table.
    (3) The /Reports and /ReportServer directories needed to be excluded from SharePoint management. I did this by issuing:
    stsadm -o addpath -url http://tfsservername/Reports -type exclusion
    stsadm -o addpath -url http://tfsservername/ReportServer -type exclusion
    (4) In order to access the SharePoint Central Administration page successfully I had to temporarily grant permission to the %systemroot%\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files folder (like simdoc also reports, above), such that a new version could be compiled.

    From what I've seen in these forums so far, I think that these points need to made clearer / stressed:
    • I know that the instructions state that you should start from an absolutely clean install of the OS. However, several people seem to have installed after removing beta 2. In that case, the MSDE instance SHAREPOINT needs to be removed.
    • SharePoint needs to be installed using the Web Farm route.
    • For those who've used beta 2, the SharePoint database has changed. It used to install the MSDE 2000 instance SHAREPOINT, but is now hosted in the SQL2005 default instance. The TFS installation handles this for you. This one confused me initially, because I hadn't realised that it had changed between beta 2 and beta 3. (Mind you, I did think it was kind of odd to have MSDE 2000 and SQL2005 installed on the server concurrently. I guess that's just a reflection of the part of the development cycle at beta 2 time??).
    I think it would be helpful if the following pre-install validation tests could be burnt into the TFS install (like the many tests that are performed before the SQL 2005 installation):
    • Ensure that MSDE 2000 instance SHAREPOINT is not installed.
    • Ensure that SharePoint is not already configured with a database (i.e. that the user has done the Web Farm install that the instructions said.).
    Tuesday, October 11, 2005 5:05 PM
  • Thanks for this really valuable feedback, and I'm sorry for the pain that you've been through trying to install team foundation server.  I'll pass on this configuration to our Test team too.

    I'm going to ensure that our doc writer for Install sees these comments.

    Bugs are filed for 2) and 4), and 4) *should* be fixed for V1 RTM.
    Tuesday, October 11, 2005 5:21 PM
  • I second Dan's comment ... thank you for taking the time to provide information
    Tuesday, October 11, 2005 5:57 PM
  • Gregory,

    Really appreciate your taking the time to provide us with this feedback

    I'm will be forwarding this around internally and look to see how we might improve the setup experience

    marc
    Tuesday, October 11, 2005 6:00 PM
  • also the requirement of the TFS beeing a domain member is a bit of a pain....

    for small systems I'd like to be able to just install as "Workgroup"
    and use local accounts on the server ...

    after all the setup does install ADAM.

    i'd rather have a set of TS accounts in ADAM for the devs and stuff as an option.

    I am a small startup / one man shop so I have to keep my hardware count to a minimum....

    and if I do not have to add a server to the domain just to install TS and use it then that keeps me from having domain accounts on my small network.

    also I have not seen much good info on how to setup SQLRS and TS and SP on different web sites -- not on default.

    by this I am talking not about different server/boxes
    just that I'd like an easy way to say:

    Install this systsem on a new IIS instance.

    also can I use TS to work on a project on that server??

    say I am developing an ASP.NET web and web service.

    say I have only 1 or 2 developers and a good server with say dual 3Ghz and 2-4 gigs of ram.
    for test and development I'd like to have
    IIS servers:

    defualt -- bare - nothing on it. maby a site I have for some other stuff
    TeamSystem -- run SQL RS,TFS etc....
    TestSite1  -- run asp.net, SQL RS, develop code.
    TestSite2  -- another web app and sql RS setup.

    now if I went to say > 3 web sites or > 3 developers I'd split the TFS and the web dev to different servers for sure....
    but for the first use I'd like to keep cost down till this new stuff shows it's worth.

    also for a shared server in a domain:  what can mix and match?
    can SQL RS run more than 1 instance with the one used by TS?
    I know some of this is really SQL  and IIS questions but I think this kind of first pass will be desired by small shops for that 1st trial run at TFS.
    Sunday, October 16, 2005 5:02 PM
  • Denny,

    It looks like you are installing Beta 2 and not Beta 3

    1. You can absolutely use workgroup w/ Beta 3, but only on a 1 box deployment.
    2. AD/AM is no longer required

    You can use Terminal Server to access TFS ... but not what you'll want for source control.  Many folks internally at MSFT use TS to access the system.

    For configuration, you only need one TFS server and you can have multiple projects running on it.  You can also do 1 project, like we do for TFS, but it has many sub areas for each of the features.  This includes ASP.NET pieces, NT Services, Web Services, SQL, etc.

    Does that help?

    marc
    Sunday, October 16, 2005 11:20 PM
  • It looks like the install suffered from not finding the virtual server in the STS_CONFIG database (my point 2, above). Here's the relevant excerpt from my VSMsi*.txt log file.

    09/24/05 15:25:14 DDSet_Entry: QuietExec started
    09/24/05 15:25:14 DDSet_Status: Commandline: "C:\DOCUME~1\TFSSetup\LOCALS~1\Temp\getadminport.exe" /adduser "
    http://TESTBOX" "Administrator" "GEODE\TFSService" "vstf@yoursite.com" "VSTF AppPool Account" "VSTF AppPool Account"
    09/24/05 15:25:14 DDSet_Status: IgnoreExitCode: 0
    09/24/05 15:25:14 DDSet_Status: Silent: 0
    09/24/05 15:25:14 DDSet_Status: ActionStart: 0
    09/24/05 15:25:14 DDSet_Status: Cost: 0
    09/24/05 15:25:14 DDSet_Status: WorkingDirectory:
    09/24/05 15:25:14 DDSet_Status: HideCmdLine: 0
    Adding user to Administrator role on
    http://TESTBOX...
    DDSet_Error: Microsoft.SharePoint.SPException: The virtual server that is referenced here is not in the config database. ---> System.Runtime.InteropServices.COMException (0x81070552): The virtual server that is referenced here is not in the config database.
       at Microsoft.SharePoint.Library.SPRequestInternalClass.OpenWebInternal(String bstrUrl, String& pbstrServerRelativeUrl, UInt32& pnLanguage, UInt32& pnLocale, String& pbstrAlternateCSSUrl, String& pbstrCustomJSUrl, String& pbstrAlternateHeaderUrl)
       at Microsoft.SharePoint.Library.a.a(String A_0, String& A_1, UInt32& A_2, UInt32& A_3, String& A_4, String& A_5, String& A_6)
       --- End of inner exception stack trace ---
       at Microsoft.SharePoint.Library.a.a(String A_0, String& A_1, UInt32& A_2, UInt32& A_3, String& A_4, String& A_5, String& A_6)
       at Microsoft.SharePoint.SPWeb.f()
       at Microsoft.SharePoint.SPWeb.get_ServerRelativeUrl()
       at Microsoft.SharePoint.SPWeb.get_Url()
       at Microsoft.SharePoint.SPGroup.a()
       at Microsoft.SharePoint.SPGroup..ctor(SPSite A_0, SPWeb A_1, SPUser A_2, String A_3, al A_4, Object A_5, UInt32 A_6, Int32 A_7, SPRoleType A_8, Object A_9, UInt32 A_10, UInt32 A_11, q A_12)
       at Microsoft.SharePoint.SPRole..ctor(SPSite A_0, SPWeb A_1, SPUser A_2, String A_3, al A_4, Object A_5, UInt32 A_6, Int32 A_7, SPRoleType A_8)
       at Microsoft.SharePoint.SPRoleCollection.GetSpecialRole(SPRoleType roleType)
       at MS.Internal.VisualStudio.Setup.Server.ManagedCA.AddUser(String sitename, String role, String userid, String email, String name, String notes)
    DDSet_Error: Failed to add user to Administrator on
    http://TESTBOX
    09/24/05 15:25:16 DDSet_Status: Process returned 0
    09/24/05 15:25:16 DDSet_Status: Commandline '"C:\DOCUME~1\TFSSetup\LOCALS~1\Temp\getadminport.exe" /adduser "
    http://TESTBOX" "Administrator" "GEODE\TFSService" "vstf@yoursite.com" "VSTF AppPool Account" "VSTF AppPool Account"' returned 0
    09/24/05 15:25:16 DDSet_CARetVal: 0
    09/24/05 15:25:16 DDSet_Status: QuietExec returned 0

    Monday, October 17, 2005 6:57 AM
  • Thanks Greg for that info (even though it means I have to start all over again!).

    Some of the stuff you mentioned, I saw earlier this summer with one of the earlier versions of TFS, but read somewhere that your 3rd point had been fixed. But obviously not!

    Also when MS speaks of a one server setup, they obviously don't mean a one server setup, since the one machine shouldn't be a DC, since it seem to require even further undocumented extras in terms of configuration.

    Just one curious thing: TFS is being released when !?
    It seems that MS needs atleast another year on this product before it SHOULD be released!

    My 2 cents

    Mikael
    Monday, October 17, 2005 2:29 PM
  • Actually, I have TFS running on a DC, so I know it's possible. I suspect that it's just the fact that the security on a DC is tighter than normal which causes the issues??

    I suspect that the only reason that my SharePoint exclusions didn't put in place is that the virtual server wasn't in the SharePoint database (see my 22:57 posting, where I've quoted the error message I had in my VSMsi*.txt log.)

    TFS is due for launch in 2006, but, personally, I don't think it's a whole year still. Jeff Beehler's recent blog entry gives me confidence that MS are getting things fixed.
    Monday, October 17, 2005 3:22 PM
  • it was downloaded recently... I'll check thouhg.

    I saw that the ADAM install was now different ... I thought perhaps it was rolled up in the main install....

    so when I get time I can take that server back out of DC and make it a member server if I want to?

    Hmmm... not sure if I will or not...

    sounds like the setup has been a changing -- perhaps due to the number of problems folks have had so far?

    thanks....
    Wednesday, October 19, 2005 2:27 PM