I've recently changed the default BackupDirectory for a SQL Server 2008 R2 instane in the registry from I:\ to K:\ and since then whenever I try to backup or restore using SSMS I'll get an error
Cannot access the specified path or file
when I browse for the path.
It happens to the root and all folders in K:\. If I key in I:\ in the path and browse, there's no such issue. I've replicated the permission on I:\ and later added the service account for SQL and MSSQLSERVER to K:\ with Full Access. I've even tried adding Everyone with Full Access and it still shows the same error. I've googled around and find a lot of similar questions but no working solution for me. I've also tested master.sys.xp_dirtree on K:\ and no error. I've even tried procmon.exe but no indication of what went wrong
K:\ is the newly created pool in our SAN allocated for backups only. The SQL Server is part of a Windows 2008 R2 Failover Cluster. Both I:\ and K:\ is configured as SQL Server's cluster resources.
Fyi, I login to SSMS using a SQL Server account, since my machine is not part of the domain. But it was never an issue with I:\ to begin with.
EDIT: There's no error if I backup/restore with T-SQL, meaning the read/write permission for SQL Server for K:\ is correct.
I had this issue but realised that I was logging into the server (in SSMS) using SQL authentication. Once I hoped on the box as a local admin and then logged in with windows authentication to SQL server, I could see the files fine.
I has same issue and found solution on another post from SO. I moved my backup file to other directory and it worked. Solution can be found here.
I tried everything on the web, but none of them successed. Then, I installed some new feature to existing SQL Server (Data Quality and Integration Service) and finally I successed to select backup file from Restore Database menu.
It Because of no (sysadmin) Privilege for your login account to SSMS; mostly.
by this way:
Open Security > Logins > Choose your account "if Windows Administrator, use it"
right click, properties > Server Roles > then check on "sysadmin" or "dbcreator" if this account must have less or specific permissions.
"Take care" you've to use another account has "sysadmin" privileges to do this step because none allowed to give himself more privileges.
I had a similar issue, when new service account has been created for SQL server. To resolve this,Add the new service account to the local Administrator group on the back up server. This can be done by loggin into the server, then computer management->users and groups->Administrator.Double click administor and add the new service account created.
Related
B"H
How can I use Azure Data Sync with localdb?
Please note: I am not asking about using it with a "Local Database" as in an on-prem database. I am speaking specifically about the technology (particular Sql Server Edition) known as localdb. As in (localdb)\MSSQLLocalDB.
The issue is adding the localdb instance to SQL Data Sync Agent. The agent must be run under an entity (windows login) that has permission to run as a service. It can not be run using a windows live identity which is what the users are usually logged in as. Yet it also needs to have permissions to the database in localdb.
Use Case:
I have a central database running in Azure. With multiple users with laptops and limited internet connection, running local apps (some built in Access). Connecting directly from the apps to Azure is too slow or otherwise impractical. Therefore I install the lightweight localdb as a cache for the users data. Which will be merged using Azure Data Sync.
I am currently using a solution built directly on Microsoft Sync Framework. However there is a maintenance overhead on that solution. So I would like to migrate to the Microsoft maintained Azure Data Sync.
Thank you
B"H
Ok, it was actually a silly mistake.
You actually can run the SQL Data Sync Agent using a windows live identity. You just need to use the local user name. Which is the name of the folder for that user in the Users folder. You must also use the name of the computer in the format MyComputer\localUserName.
Once I was running the SQL Data Sync Agent under the currently logged in user - who also has access to the DB - everything else ran smoothly.
Here's the error message that is stumping me:
My Web App seems to have the correct connection string. This is exactly what Azure provides me when I click Show Connection String:
Server=tcp:myservertest.database.windows.net,1433;Initial Catalog=MyDatabaseTest;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Here's the connection string that I put in the Visual Studio Publish Settings Default Connection setting:
Server=tcp:myservertest.database.windows.net,1433;Initial Catalog=MyDatabaseTest;Persist Security Info=False;User ID=*****;Password=***********;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
I have confirmed the username and password are correct...I used the same ones to connect via Microsoft SQL Server Management Studio.
I tried setting up the Diagnostic settings as follows, but I'm not exactly sure where I can find the resulting logs. I don't see them in Kudo services, but I believe they'd be accessed elsewhere.
Does anyone know where they're stored?
Also, what other ways could this Login failed for user error message be debugged?
The error looks like you are able to connect to the server but the server rejects the login. Debugging in the server logs would help, so you are looking at the right place.
You can enable Azure SQL Database Auditing & Threat Detection. You can enable it on SQL Server instance level by opening your SQL Server resource and selecting Security / Auditing & Threat Detection. Select a storage account to store logs in Storage details (see picture below). For more information, see https://learn.microsoft.com/en-us/azure/sql-database/sql-database-auditing.
After enabling auditing try to login to your database. After that you can find the logs in the specified Azure Storage Account in blob container named sqldbauditlogs. The logs are in folder /servername/databasename/SqlDbAuditing_ServerAudit_NoRetention/yyyy-mm-dd/ in files with xel extension. You can download and open the .xel -file in SSMS (File / Open / File…). The xel file contains events and you can see login attempts there.
Event field succeeded tells if the login failed or not, and field server_principal_name contains the username in both cases.
From text in field additional_information you can find error_code (in the xml). Error code 40615 is blocked by firewall and code 18456 is wrong username or password. (error codes from https://learn.microsoft.com/en-us/azure/sql-database/sql-database-develop-error-messages)
You can also find some information in the database system tables for analysing the connections, e.g. sys.event_log (see: https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-event-log-azure-sql-database?view=azuresqldb-current).
More information on troubleshooting the Azure SQL Database connectivity can be found here: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-troubleshoot-common-connection-issues.
I hope this helps you forward with debugging the connection.
You've verified that Allow access to Azure services is ON. This is generally where we get tripped up. If it was coming from an outside place, we'd want to check the IP list here. Knowing that's not it, let's dig deeper.
You've gotten into the Kudu console to verify all the things. From that console, install mssql-cli. Run pip install mssql-cli from the Kudu console. If that doesn't work, look for direct urls curl or download to your PC and use the Kudu Console to upload the file into your app service.
Once you have the mssql-cli installed, try connecting with the credentials you've set in place in appSettings.json. (See https://github.com/dbcli/mssql-cli/blob/master/doc/usage_guide.md#options for command line options.) Most probably, it'll spit out a nice error message about why it can't connect, giving you more clues.
If mssql-cli connects successfully, there's something overriding your app's settings. Did you set the connection string in the Azure Portal's App Settings tab? Temporarily, you might alter your app to write portions of the connection string to an obscure page. And as soon as you get the info, DELETE THE PAGE and then change the password.
Another thing to try: grab all the details from the exception -- including Data and recursively through inner exceptions. It probably has a clue buried in there. You can remotely debug the app on Azure. Before you can debug, you'll need to ensure you've turned on remote debugging and selected the correct version of Visual Studio from the App Settings blade in your App Service.
Continue from comment - Where in Kudu would that be found? Justin in the general file explorer?
Go to Debug console > CMD - site > wwwroot - click Edit icon
Also ensure that Allow access to Azure services is ON.
Sometimes you need to check the connection string on azure application in azure. Maybe the connection string is different from the one in your web.config
I am attempting to move TFS from SERVERA to SERVERB. I am using this MSDN article as my main resource for accomplishing this. I have installed SQL Server (same version) on SERVERB. I have backed up the SERVERA TFS databases. I installed TFS but did not configure on SERVERB. On SERVERB, I used the TFS admin console and clicked restore databases and navigated to the network location of my backup. After selecting the backup set there are a few more screens to go past but eventually I get the below error during the readiness check. I am logged in as a domain user who has local administrator rights (in the local administrators group). I believe that if I can solve the TF400998 error the other errors (TF246017) may go away as well. The error refers to "The current user". If that means my domain user, then what exactly is the restore looking for?
Edit: I will rephrase my question. Since my domain account is a powerful user on the system, what permission might be missing? Also, this account has the sysadmin server role in SQL server.
You can try to use NT AUTHORITY\NETWORKSERVICE as SQL Server service account and have a try. Also see the below threads to solve the issue:
TFS 2010 Backup fails with "The current username failed to retrieve MSSQL Server service account. "
Backup plan wizard generates an error
I'm running Windows 7 SP 1 and have just turned on IIS 7. Just trying to access the default page it creates I get a 503 error, and the application pool stops. I look in the event log and I find the error:
Windows cannot copy file \?\C:\Users\Default\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm to location \?\C:\Users\TEMP.IIS APPPOOL.000\AppData\Local\Microsoft\Windows\Temporary Internet Files\SQM\iesqmdata_setup0.sqm. This error may be caused by network problems or insufficient security rights.
DETAIL - Access is denied.
I tried making the TEMP.IIS APPPOOOL.000 folder available to everyone. I tried making Users available to everyone. No luck, it still dies with the same error.
What is happening here, and how can it be fixed?
It sounds like you're having the same problem as details in this IIS.NET forums thread. You didn't mention if you have x64 Windows 7 or not. Suspect that your development machine is misconfigured somehow; sounds like the uninstallation and reinstallation of IIS7 would help/fix.
Suggested courses of action:
Open IIS and its Application Pools. Open "DefaultAppPool" and any other Application Pools in use.
Click Advanced Settings for each of these. Ensure the "Load User Profile" is set to 'False'
Also ensure that the "Set Application Pool Defaults" has the Load User Profile set to False."
I encountered the same problem in my development environment (Windows 8.1). Instead of disabling the load user profile as suggested by P.Campbell, I went ahead and changed the permission of the sqm file to allow modify accesses for IUSR, IIS_IUSRS and Network Service. In my case, the sqm file was not able to show me the file owner in which I taken over with my user account.
Basically, my problem was solved by giving the correct permission for both source and destination files/folders.
Found the answer here - http://forums.iis.net/p/1180636/1992024.aspx
Open IIS Manager
Find the App Pool that is causing the problem
Open Advanced Properties
Change 'Load User Profile' to false
Fixed!
After struggling with all these Application Pool issues in IIs, I found the problem and the solution. This may help you.
Each application pool on each website in Microsoft's Internet Information Server creates its own user account and folder under the "c:\Users" directory when the pool is created and first run. Its actually a virtual user account and should be named for the Application Pool assigned to your web application in IIs. In most development environments, its the default website or "DefaultAppPool". It uses this temporary user account to run the pool. Each website should have a named user pool account. This User folder is used by the pool and ASP.NET for caching and writing of file resources and other things used by IIs, ASP.NET, and this virtual account.
In some setups people are not seeing this folder but a "TEMP" folder (like you have) when the IIs web site is accessed and using the pool.
If you instead see a "TEMP" folder in the Users folder you have a broken application pool account in IIs and in the Registry. The pool is creating the TEMP folder as a backup for this virtual account, which might not have the right security setup. I had this exact scenario.
To fix it go to the registry under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
See if you have a SID user account with the ".bak" extension for a DefaultAppPool user account. If so delete it and restart your PC. Test your website again, making sure its actually setup to use DefaulAppPool. It should now recreate the "DefaultAppPool" folder in Users, recreate the registry entry for DefaulAppPool user, and your error should go away.
You can delete the TEMP user folder at that point under the Users folder. (Keep in mind if your web app has been storing cached information critical to users of the website, some of that might have to be inserted into the new DefaultAppPool user folder. But for most of us, just delete it.)
I also found I had to add this kooky virtual application pool account to my local database so the worker process and app pool accnt could have the rights to grab data from SQL Server: Just go into SQL Server and under logins add "IIs AppPool\DefaultAppPool" and then assign it as a user to your databases.
(btw whomever dreamed up this virtual application pool account system is nuts....its way too complicated and convoluted to sort out)
After I did this, all my stack overflow errors went away in Visual Studio for my web application, all data connections fired perfectly, all write permission to the default User profile stored properly, and all the restarting and crashing of the Application Pool in IIs ended completely. :)
Doing some more tinkering with development on VS2008/Vista/IIS7, I'm wondering at a few things regarding the Network Service account. It had no issues running my website until I attempted to set up the Sql Role Membership Provider, which creates a local database in the App_Data folder. Somewhere in there, Network Service ran out of the permissions needed to auhenticate my client.
I solved the problem by changing the app pool to run under my admin account (and later by granting Network Service admin permissions for now), but I'm curious as to what permissions Network Service is missing as I'd ultimately like to keep it (and my sites) out of the admin group. Any ideas?
Also, where's a good place to go debug this stuff? EventLogs have nothing useful, so I'm not sure where else would be a good place to find out when an account tries to do something and is denied. Maybe I just don't have the logs configured properly?
Thanks!
Oddly enough, it looks like gving Network Service write access to the folder containing the mdb file wasn't enough. It apparently wants read access to everything under the "Documents\Visual Studio 2008 directory" as well (the site is hosted from within that directory). Seems ok now. Thanks ProcessMonitor!