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.
Related
I have TFS 2013 Update 3 installed on a machine and I'm trying to configure the TFS Build service on another machine on the same domain. The registration of the build service completes successfully but the service, controller, and build agents go into an endless start/stop/restart loop. The event viewer on the build machine gives the following error in the Build Services Operational log:
Build machine 'x' lost connectivity to message queue tfsmq://buildservicehost-18/.
Reason: TF30063: You are not authorized to access http://tfs2013:8080/tfs/defaultcollection.
Things I have tried:
Both NetworkService account and a domain account for the build configuration
Unregistering/re-registering the build service
Uninstalling TFS on build machine and reinstalling
Creating a fresh server 2012 install, installing TFS build component on it
The domain account I tried to use was in the build service account group for the collection and I've even tried putting it in the admin group. I also tried running it as my own domain account which is a tfs admin and domain admin account. All with the same results. The fact that this occurred on 2 different machines, one with a completely fresh everything install leads me to believe the problem is on the TFS application tier itself but I have no idea where to go from here. Visual studio is able to connect to TFS just fine for all users.
It sounds like you have a TFS 2012 server that you are trying to connect a TFS 2013 build agent to. This is not a supported configuration.
It is recommended that your build Agents version of TFS matched the version on the server. This does not mean that you can't build with any version of MSBuild or VS that you want on that agent. That's configuration.
I ended up resolving this by doing the following:
Detach Collection
Backup Collection as a precaution
Uninstall TFS 2013 from the App Tier (which is also the Data Tier)
Re-install TFS 2013 and configure it for single server like it was without creating a collection
Attach the existing collection
Uninstall TFS on the build server
Re-install TFS on the build server and configure the service, controller, and agents.
This worked fine and didn't cause me to lose anything. I still don't understand why I was having problems in the first place but my only guess is that it was some type of remnant from doing a migration based upgrade from TFS 2010.
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.
I need to install a SQL Server 2008 database on several user machines. The users are not technically proficient, so I cannot create a script and just give it to them. I need to be able to create an executable that will create the database. The executable will check if the user has SQL Server 2008 Express installed, then install the database. The executable will install the database using Integrated Security, so I don't need the user's id or password.
I tried using the database project in Visual Studio 2010, but it just creates scripts.
Is there an open source solution to creating an executable that installs SQL Server databases?
May I suggest that you look at embedding SQLServer 2008 Express within your application.
Check the Microsoft link here.
Then you can check for an SQL instance and install one if it doesn't exist when the program first starts up.
A simple way would be to use SQL Server Management Objects (SMO) to create a .NET console application that creates the database.
Depending on your security rights on your user's machines you may be able to run the app from your workstation and deploy directly to their machines.
SMO can also be driven by powershell.
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
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