I'm having problems installing development machine for Sharepoint (Foundation) 2010. This is what I did so far on the same machine:
Installed a clean Windows 7 x64 with 4GB of RAM without being part of any domain. Just a simple standalone machine.
Enabled IIS related features as described here except IIS6 related ones (two of them)
Installed SQL Server 2008 R2 Development Edition (DB Engine and Writer being enabled but not SQL Agent)
Installed Visual Studio 2010 Premium
Started installing Sharepoint Foundation 2010 with first extracting files, changing config to enable Windows 7 installation and then installed it as Server Farm (then Complete) to avoid installing SQL Express.
Created a separate SPF_CONFIG local user with Logon on as a service right.
Opened SPF Management Shell and run New-SPConfigurationDatabase so I am able to use a non-domain username (SPF_CONFIG that I created in the previous step)
But all I get is this:
The outcome after this error is:
Database Sharepoint2010Config is created
User SPF_CONFIG is added to SQL Server and attached to this newly created database as dbowner
Checking SQL server security logins this user has following rights:
dbcreator
securityadmin
public
Resolved it myself after trying all kinds of things
The main thing is I haven't given up and installed stadalone installation.
I've followed two guides:
this blog post
and this MSDN resource
Step by step instructions I followed (may be helpful to someone else as well):
Then I've uninstalled SPF2010
Setup all accounts as described in the first document
Reinstalled all prerequisites and KBs described in MSDN resource.
Cancelled configuration wizard and ran Sharpoint PowerShell
Executed
New-SPConfigurationDatabase -AdministrationContentDatabaseName "SomeDBName"
Command than asked me about all other missing info
Waited for the command to finish (few minutes)
And it succeeded
FINALLY!
Rerun psconfigui and finished configuration
Successfully launched SPF Admin Web.
clap clap clap
Related
We recently migrated from VS 2008 to VS 2013 including a set of setup projects. One of the setup projects is meant to install a web application. It has one custom action that is meant to check the connection to the database. The code of the custom action has not been touched during the migration and the .msi works perfectly when generated from VS 2008. When I built the .msi from VS 2013 it works perfectly well when installing on our local development server, and throw an error saying that it cannot connect to the db when rolling out in the clients environment.
I'd really appreciate if anyone can point me into direction of search here. I know that I'm passing a correct connection string, and .msi generated from VS 2008 can connect to that db from the same server.
Visual Studio custom actions that are installed for Everyone will run with the local system account. Connecting to a SQL DB will often fail because the DB doesn't allow the system account to connect, or because the DB is on a network share and the system account has no network privileges.
So it could fail because of the security settings of the DB or because the DB is on a network, and it may be nothing to do with the server. It might also connect if the install runs with a Just me setting because the custom actions then will run with the installing user's credentials. There may also be issues with architecture because servers are 64-bit and the 32-bit subsystem is optional, and you didn't say whether you install was x64 or your custom action code.
Anybody able to successfully install/configure Release Management Server for TFS/Visual Studio 2013?
Went through simple install of SQL Express 2014/Release Management Server on both Win 8.1 Pro and Win Server 2012 R2 and the attached image is the result.
Interface appears to be missing many components, as if permission or some other IIS setting is incorrect.
Tried in both Chrome and IE with the same result.
Used default install settings (Network Service account) and currently running SQL Express on same machine as Release Management install.
This is the interface for RM's Release Explorer and it does look like that, unbelievable as it may seem. All this will change with new RM components in TFS 2015 - check out Donovon Brown's talk at Build 2015 for a preview.
Back to the root of your issue, which is that Release Explorer is only a minor part of the RM stack. Have you installed the RM client (a WPF application) which is the main interface for configuring RM? My continuous delivery with TFS blog post series here has all the details you need.
I have a web application implemented in ASP.NET MVC3 and SQL Server 2008 Express. It's relatively small so I can deploy it in local computer of my clients (Windows 7 or higher).
Currently, I deploy it manually by create new web site in IIS, copy published files to the folder of website, install SQL Server 2008R2 and use Management Studio to restore database with some initial data.
It's OK with me but not with my clients. They can't do the same things. What I want is an automatic installer, my clients just need to click a few buttons to get all done.
Specifically, this automatic installer must do the following things:
Install SQL Server 2008R2 Express and restore the initial database.
Install IIS7 (if it's not enabled in Windows 7).
Create a new app pool (V4) and a new Web Site use this pool. Then copy published files to the folder of the Web Site.
The installler can run aspnet_regiis command and grant permission for NETWORK SERVICE account to TEMP folder. This is required for web site to run.
The installer can copy some fonts to Font folder of Windows.
I see many app can do this automatic installer, but after googling I can't find a thorough solution to try.
Please give me some advice on this. Thanks in advance!
If you want a free solution, WiX is what you need, but it will take you some time to learn using it if you never created a package with it.
A more easy to use, and also powerful, but payed tool, is Advanced Installer, you need Professional edition, but you can try it for free with the 30 days trial mode. It has predefined prerequisite for SQL Server Express, built-in support to install IIS entities, and set file/folder permissions. Bassically all the requirements you need.
To enable any IIS feature you can simply add a PowerShell script.
My company is interested in better integrating our investment in VMWare with our TFS deployment. Currently the company is running TFS2005 SP1, VS2010, and we have a sizeable SAN that we would like to use in environment reproduction similar to what is offered in TFS2010 Lab Management.
Of the features offered by TFS2005, we are currently leveraging only TF Version Control--work items and build automation are handled by separate systems. However, we would like to use the TFS-integrated Symbol/Source server in order to accurately debug the different versions of our product, and that's where we're running into difficulty.
The VMs deployed in VMWare are not joined to the corporate domain, and this means that we run into difficulty when attemping to grab source code information via Source Server and the "tf.exe view" command.
If devenv is run on the VM, it can't authenticate a domain account, and tf.exe view fails when grabbing source info.
If devenv is run on the developer desktop and debugging is done with remote debugger, the vm's local user account fails to access the share exposed by Symbol Server and can't load symbols to begin with, much less retrieve source.
Has anyone done this before?
Yes - You can still do this. If you are using Windows 7 (and I believe Windows Vista) you can always add the domain credentials to the "Credentials Manager" in the Control Panel. This will help it authenticate for the TFS URL whenever it needs to talk to TFS.
BTW, I have a blog post discussing the Symbol Server and Source Server features of TFS 2010 available here: http://bit.ly/SymbolServerTFS
What are the best practices in setting up a new instance of TFS 2008 Workgroup edition?
Specifically, the constraints are as follows:
Must install on an existing Windows Server 2008 64 bit
TFS application layer is 32 bit only
Should I install SQL Server 2008, Sharepoint and the app layer in a virtual instance of Windows Server 2008 or 2003(I am already running Hyper-V) or split the layers with a database on the host OS and the app layer in a virtual machine?
Edit: Apparently, splitting the layers is not recommended
This is my recipe for installing TFS 2008 SP1.
There is no domain controller in this scenario, we are only a couple of users. If I was to do it again, I would consider changing our environement to use a active directory domain.
Host Server running Windows Server 2008 with 8GB RAM and quad processor
Fresh install of Windows Server 2008 32bit in a VM under Hyper-V
Install Application Server role with IIS
Install SQL Server 2008 Standard edition
Use a user account for Reporting Services and Analysis Services
Create a slipstreamed image of TFS 2008 with SP1 and install TFS
Install VSTS 2008
Install Team System Explorer
Install VSTS 2008 SP1
Install TFS Web Access Power tool
After installing everything, reports were not generated. Found this forum post that helped resolve the problem.
Open p://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx
Run the webservice (see above link for details), it will take a little while, the tfsWarehouse will be rebuilt
It is very important to do things in order, download the installation guide and follow it to the letter. I forgot to install the Team System Explorer until after installing SP1 and ventured into all sorts of problems. Installing SP1 once more fixed that.
One critical thing you has to keep in mind about TFS, is that it likes to have the machine all to it self. So if you have to create a separate instance on Hyper-V do it using the proven Windows Server 2003 platform with SQL Server 2005.
I am sure Microsoft has done a great job getting it to work under Windows Server 2008 and SQL Server 2008, however you don't get any additional features with this newer install and it is currently unproven in the wild.
So my recommendation is to stick with what is known until the next release of TFS comes out.
Also splitting the layers is definitely not recommended, especially in the workgroup edition where you will only be allowed to have 5 licensed users. Those 5 users will never exceed the server's needs. Also my recommendation is to not update Sharepoint if you don't need to. In my environment, we don't really use Sharepoint all that much, so I left it alone. Sharepoint is usually, in my experience, where most of the problems come from with TFS.
I just upgraded our team to TFS 2008, from TFS 2005. The hardest part was upgrading SharePoint 2.0 to 3.0, so I would make sure to do that first, if you have not already installed TFS 2008. We had a couple of other difficulties, but they were all either related to the SharePoint upgrade, or to the fact that we were using an aftermarket Policy package - Scrum for TeamSystem. We are on SQL Server 2005, so I cannot address SQL Server 2008. As for splitting the layers, we did not do this either, as we are running on Windows Server 2003 and everything ran under the host OS.
Splitting the layers is only needed for more than 450 users.
I would also recommend having the Build Server on a completely seperate machine. Building is very file system intensive. SQL Server performs best when it has complete control of a file system - so having build and TFS on the same machine may create performance issues while builds are executing.
Perhaps this can be alleviated with proper tuning and seperate physical drives - but I'd think in the long run it would be a lot simpler to just either use some old hardware - or spin up a small virtual machine on a seperate host for your builds