I have an issue where we tried to upgrade our TFS 2005 server to 2008. During the install we encountered the error that it could not configure SQL Reporting Services. The log files showed that during the creation/configuration of the virtual directories for SQL Reporting Services (the Reports directory to be exact) a FileNotFoundException was thrown. The directory was actually created. SQL Reporting services were running just fine before the install. I tried to go in and reconfigure manually with the report server configuration tool but while it will create both directories, it still fails with a FileNotFoundException. I manually configure the .config files to point to the current server and I am able to get the sql report services web site running. We tried several things: messing with permissions, application pools, reinstalling the .NET framework, aspnet_regiis, etc. but nothing has changed the error.
Any ideas?
I recently encountered a similar problem. After installing a new RS instance and applying SQL Server sp2 and the KB954606 hotfix, I attempted to configure the RS instance, but creating the virtual directory failed. As in your case, the virtual directory was created, but the RS configuration tool threw an error.
In my case, deleting the newly-created virtual directory using IIS manager and then rebooting the server fixed everything. I was able to successfully create the virtual directories using RS Configuration Tool following the reboot.
Related
After using Team Foundation Server (TFS) for years, we suddenly lost the ability to connect either through Visual Studio (VS) or via URL. To the best of my knowledge, no changes were made to the virtual server that supports TFS.
In VS the error is:
TF400324: TF services are not available from server... Unable to connect to the remote server...
If I use the {server}:8080/tfs or localhost:8080/tfs url in a browser it tells me the connection was refused.
In the SQL Management Studio both the Tfs_Configuration and Tfs_DefaultCollection databases appear to be connected, and show a "Ready" status. In the TFS Administration Console the DefaultCollection state is "Online".
Perhaps the best clue is that if I use netstat to see which ports are in use on the server, port 8080 is not listed at all. Is there a listener service that needs to be started?
I see that the following services are currently disabled: UPnP Device Host, SSDP Discovery, Internet Connection Sharing, SSDP Discovery, Internet Connection Sharing, Smart Card, Routing and Remote Access, Net.Tcp Port Sharing Service, and Computer Browser.
Of course, we have tried a reboot to no avail.
Any troubleshooting suggestions will be much appreciated, as this has begun to impact our productivity. Thanks in advance!
Edition: TFS 2015
Version: 14.114.28805.0 (Update 4.2)
Update:
I should mention that the firewall has been disabled in attempting to diagnose the issue.
Also, there are errors associated with TFS in the Even Viewer, but they are not at all clear. Here are is a snippet:
VssRequestContext.HostManagement.Microsoft.TeamFoundation.JobService.Extensions.Core.IdentitySyncJobExtension.Run:1
Registry.TeamFoundationRegistryService.Write:1
Default.SqlResourceComponent.Execute prc_UpdateRegistry ds:LT-TFS2
db:Tfs_Configuration:2 Default.SqlResourceComponent.Execute:-3
Registry.TeamFoundationRegistryService.Write:-3
GroupComponent.SqlResourceComponent.GetGroupsToSync:3
GroupComponent.SqlResourceComponent.Execute prc_GetGroupsToSync
ds:LT-TFS2 db:Tfs_Configuration:3
GroupComponent.SqlResourceComponent.Execute:-4
GroupComponent.SqlResourceComponent.GetGroupsToSync:-4
GroupComponent.SqlResourceComponent.ReadGroups:4
GroupComponent.SqlResourceComponent.Execute prc_ReadGroups ds:LT-TFS2
db:Tfs_Configuration:4 GroupComponent.SqlResourceComponent.Execute:-5
SOLVED!
I found that the TFS site was disabled within the IIS Manager. When I tried to enable it, it reported that the World Wide Web Publishing Service was disabled. Enabling both resolved the issue.
This error is usually related to TFS cache. You could give a try following below steps:
Close all instances of Visual Studio
Open the Task Manager and check if any TFS Services are running. Select each of them and click on End Process Tree
Browse to the folder %LocalAppData%\Microsoft\Team Foundation\ and then select the folder with your TFS version and go inside
the Cache folder. for example, the path was
%LocalAppData%\Microsoft\Team Foundation\x.0\Cache and it should be
the same on your machine with the difference of the TFS version folder
name.
Delete everything in that Cache folder.
Start Visual Studio and run it with Admin mode.
Besides, in case of your TFS is configured with self-signed TLS/SSL certificate.
If this is the case, you need install that certificate to the Trusted Root Certification Authorities store on the client machine, where you have VS.
For this scenario, you could refer this answer.
Moreover, please also check if there are any errors in the event viewer in your TFS server. This may help to narrow down the issue.
Here is the short version of the problem: I have a discrete DTSX file that works fine on our Production server, but doesn't on our new Dev server.
Symptom: When run from a SQL-Server job, the job starts and nothing at all happens, and it never finishes... it just hangs, using very little system resources.
Some info: For Prod, the packages were developed on SQL-Server 2012 and run on an NT 2008 server. The new Dev server is also SQL-Server 2012, but runs on an NT 2012 server (in case that matters). I have duplicated the folder/file structure exactly, including drive name. The package uses an external dtsConfig file, but as I said - the folder/file structure is identical.
The SSIS service, SQL-Server Agent, and my remote login are all the same, and is a member of the server Administrator group on the Dev box. If I copy the command line text from the SQL job and run it in a CMD window using dtexec.exe, the package executes correctly. The job owner is my login, and the "run as" is the SQL-Agent, which - as I mentioned - is the same login. Since everything in the package uses integrated security, everything should be running using the same login whether on the command line or via the SQL-Agent, which should eliminate any user permission/credentials issues.
I tried adding SSIS logging to the package, logging everything I could. When I run the package from the command line, I get a ton of messages in the log. When I run the package via the SQL job, there are no messages at all in the log - nothing.
Whatever is going on, it's not getting far enough into the SSIS package to generate a single log entry. It's just stopping but not exiting or throwing an error. FWIW - I have the same problem with every other package I've tried.
Any ideas are appreciated...
I found the cause of the problem. The MS-SQL Server service was using a different login than the SSIS server service and the NT Agent service (it was using a local service account).
Once I changed the MS-SQL Server login to match the others (and restarted the service), the job ran correctly.
I had a new machine which windows crashed and I had to do a Windows reset which reinstalled Windows. Afterwards I deleted the old app user accounts in the C:\Users folder since the reinstall didn't delete it, these included SQL Server MSSQLServer and .net accounts because I was going to install all the apps from scratch I decided to clear it up and delete it.
I then ran SQL Server 2014 SP1 setup selecting database engine, client connectivity and Management Studio on default instance MSSQLServer
using mixed mode authentication and added my own sa password and my current windows user.
At the end of my installation I notice the installer takes a very long time at the following step
SqlEngineDBStartConfigAction_install_configrc_Cpu64
I then get an error
The following error occurred:
Could not find the Database Engine startup handle.
Logs
Feature: Database Engine Services
Status: Failed: see logs for details
Reason for failure: An error occurred during the setup process of the feature.
Next Step: Use the following information to resolve the error, uninstall this feature, and then run the setup process again.
Component name: SQL Server Database Engine Services Instance Features
Component error code: 0x851A0019
Error description: Could not find the Database Engine startup handle.
Error help link: http://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=12.0.4100.1&EvtType=0xD15B4EB2%400x4BDAF9BA%401306%4025&EvtType=0xD15B4EB2%400x4BDAF9BA%401306%4025
I open SQL Server configuration manager Services and noticed my MSSQLServer doesn't start up because it runs as NT Service\MSSQLSERVER user. I change that to local system account and start the service and the service runs.
However when I open SQL Server Management Studio and try to connect to the database engine I can't connect with neither my windows user I added during the SQL Server setup nor the sa user with password I specified.
Cannot connect to PCName. Login failed for user PCName\User. Microsoft SQL Server Error 18456
When I uninstall SQL Server and reinstall it I get the same issue. Even when I delete the program files directory C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER
How do I get it to work?
Why does a new SQL Server 2014 SP1 installation not create the MSSQLServer user?
How to I create the MSSQLServer user manually and what permissions and groups do I assign to it?
I tried everything to resolve it. Delete all the SQL Server folders. Remove registry entries as mentioned in other stackoverlow answers. Installed SQL Server 2014 SP1 again and the problem still occurs.
Even when I installed SQL Server 2012 SP1 on the default instance I would still get the error.
The only workaround I could get it to work was to install SQL Server as a separate instance and not the default instance.
This made me thinking if the issue is only related to the default instance.
I looked at my C:\Users folder and the default instance MSSQL user folder was not there meaning the installer never created it. The problem must have occurred that I previously deleted the User folder to clean up the machine where I should have deleted the windows users from Control Panel Admin Tools instead.
Solution: Use regedit.exe
The problem entry should be the corresponding S Folder in.
HKEY_LOCAL_MACHINE - SOFTWARE - Microsoft -Windows NT -CurrentVersion -ProfileList
Delete this user
Reinstall and verify in the C:\Users if the MSSQL user gets created.
I tried to be safe and deleted all references to the MSSQL user in the registry user after uninstalling all SQL Server references in Add/Remove Programs and clearing up the Program Files folders the one registry item is probably the cause.
This solution helped me to fix the issue.
I had deleted MSSQLServer and SQLAgent account while cleanup of SQLServer2016, but then MSSQLServer 2016 installer wasn't getting re-installed, reason being it could not create the service account, and my application is limited to support "only default SQL instance"
I have followed this and deleted the REG entries and this helped me to reinstall SQL Server smoothly.
Thank you so much .
Solution: Use regedit.exe
The problem entry should be the corresponding S Folder in.
HKEY_LOCAL_MACHINE - SOFTWARE - Microsoft -Windows NT -CurrentVersion -ProfileList
I have the following situation:
A sql server 2014 is installed
While the server was shutdown the hard drive the databases were on had troubles which resulted in the loss of these files
So now I have the situation that the server has databases configured to be existing where the files don't exist any longer.
When I now try to start the sql server via the configuration tools it does not start and in the log files I see that he throws an error that he doesn't find the database files. When I tried to copy the same files there from another server I still had the same problem but the error message was now "access denied" (as naturally they had different users).
So my question is: What (aside from a reinstall) can I do to get the sql server up and running again?
Change the database file permissions to allow access for SQL Server. Look at an existing file to see what permissions must be configured.
I'm having a rather frustrating issue with using an SSIS Flat File source. I am developing an SSIS package on my local machine via VS 2008 and I'm using a flat file source that is stored locally. However, I need to deploy this package to a remote server that hosts our SQLServer and then run it as a scheduled job from that host. However, when I deploy the package, it obviously can't read the flat file source from my machine and fails the job. I have tried putting the file directly on the remote host in the exact same file location (ie. C:\Source.txt) but to no avail. Any ideas on how I can get my deployed SSIS package to read a flat file source?
Hopefully I'm just missing something extremely simple and will ultimately have a "DUH" moment, but if anyone can help I will greatly appreciate it.
If the account under which the SSIS package (for instance the SQL Server Agent service account) is running doesn't have rights to open the file, you will also have problems. So not only does the file need to be on a path that is valid relative to the server running the package, it must also have rights.
Nice answer by Cade.
Remember that you create a SQL Server Job, by default it runs under the credentials of the Service Account assigned to the SQL Server Agent.
If some steps on a Job need some permissions not owned by the Service account you can define a SQL Server Agent Proxy.
That way you can keep the principle of least privileges.
More info on how to create a Proxy here.