On Windows Server 2008, is there an easy way to modify security permissions for multiple files at once (as with Windows Server 2003)? Right-click - properties does not provide a "Security" tab if more than one file/directory is selected (i.e. ctrl-click multiple files).
As well, short of making registry changes, is there a way to edit files in notepad without having to open up notepad as an administrator? As it is, because of UAC you must open Notepad as an admin and then open the file you wish to edit (otherwise, cannot save).
UPDATE: Moved to https://serverfault.com/questions/30991/windows-server-2008-change-security-settings-for-multiple-files-at-once
ANSWER TO PART B: "As for editing the files: if you give regular (non-admin) users write permissions to the files, you don't have to run notepad as admin." Thanks #Martin v. Löwis
As always, there is cacls.exe (or xcacls) to change the ACLs for multiple files. Dunno whether you would call that "easy".
As for editing the files: if you give regular (non-admin) users write permissions to the files, you don't have to run notepad as admin.
Related
Every time I log into the Accurev plugin in visual studio 2012 I have to re enter the server information. Has anyone else run into this issue?
What version of Windows are you running and what are the User Access Controls (UAC) settings for the system? Higher UAC settings will block writing to files located within the "Program Files (x86)" directory, which is where AccuRev is installed and maintains the "acclient.cnf" file. This is the file that lists which servers are available for you to login. Open this file with a text editor, add the server you login to by adding a line like the following:
SERVERS = myserver:5050
Please notice the spaces before and after the equals sign is intentional and needed. Your server name can use either the short name of the fully qualified domain name. The number after the colon is port number that AccuRev uses for establishing connections.
This file is located in the "AccuRev\bin" directory.
I have a windows form application that requires users to log in to access the information. I have created a local compact database file for the credentials to be stored. I added the database file to my the folder but when I open my application and try to log in it tells me that it cannot find the database file.
Should the file be stored on a different folder, or should I need to install an instance of sql on the user computer.
This is my first deployment so I am not sure how to go about it. I have done some research on the subject, but it does not seem related to my issue. The help section of Intallshield was not clear either.
I am looking for some resources on how to accomplish this.
I figure out the issue, in order to work all files, including the database files need to be dumped under the userprofile folder.
My .NET app updates a certain .xls file located in a shared folder inside the domain. Using VB.NET, how can I check if that file is being used by another user and unshare/close it, so my code can update the file properly?
NOTE:.Exe file(my app) will be executed in the server where shared folder is.
Windows and NTFS is designed to prevent this scenario. Unless you:
Get the Excel application which is holding the .xls file open to close it
Shut down the server's network connection assuming the Excel file is opened by client PCs - a highly undesirable step to take
Discover the PC on which the Excel.exe instance is running and use the Windows Taskkill command-line command to kill all Excel.exe instances (since you won't necessarily know which one has it open) on the machine - another undesirable step to take
Have a look at this answer, but this uses third-party utilities, and doesn't explain how these utilities do what they do though you may be able to Process.Start them.
you just can't get Windows/NTFS to release the file lock.
A possible alternative that I'm not sure will work with an xls (as opposed to an xls_) is to make the file shared, though this has some limitations.
Where would you write an error log file, say ErrorLog.txt, in Windows? Keep in mind the path would need to be open to basic users for file write permissions.
I know the eventlog is a possible location for writing errors, but does it work for "user" level permissions?
EDIT: I am targeting Windows 2003, but I was posing the question in such a way as to have a "General Guideline" for where to write error logs.
As for the EventLog, I have had issues before in an ASP.NET application where I wanted to log to the Windows event log, but I had security issues causing me heartache. (I do not recall the issues I had, but remember having them.)
Have you considered logging the event viewer instead? If you want to write your own log, I suggest the users local app setting directory. Make a product directory under there. It's different on different version of Windows.
On Vista, you cannot put files like this under c:\program files. You will run into a lot of problems with it.
In .NET, you can find out this folder with this:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
And the Event Log is fairly simple to use too:
http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx
Text files are great for a server application (you did say Windows 2003). You should have a separate log file for each server application, the location is really a matter of convention to agree with administrators. E.g. for ASP.NET apps I've often seen them placed on a separate disk from the application under a folder structure that mimics the virtual directory structure.
For client apps, one disadvantage of text files is that a user may start multiple copies of your application (unless you've taken specific steps to prevent this). So you have the problem of contention if multiple instances attempt to write to the same log file. For this reason I would always prefer the Windows Event Log for client apps. One caveat is that you need to be an administrator to create an event log - this can be done e.g. by the setup package.
If you do use a file, I'd suggest using the folder Environment.SpecialFolder.LocalApplicationData rather than SpecialFolder.ApplicationData as suggested by others. LocalApplicationData is on the local disk: you don't want network problems to stop you from logging when the user has a roaming profile. For a WinForms application, use Application.LocalUserAppDataPath.
In either case, I would use a configuration file to decide where to log, so that you can easily change it. E.g. if you use Log4Net or a similar framework, you can easily configure whether to log to a text file, event log, both or elsewhere (e.g. a database) without changing your app.
The standard location(s) are:
C:\Documents and Settings\All Users\Application Data\MyApp
or
C:\Documents and Settings\%Username%\Application Data\MyApp
(aka %UserProfile%\Application Data\MyApp) which would match your user level permission requirement. It also separates logs created by different users.
Using .NET runtime, these can be built as:
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
or
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
followed by:
MyAppDir = IO.Path.Combine(AppDir,'MyApp')
(Which, hopefully, maps Vista profiles too).
Personally, I would suggest using the Windows event log, it's great. If you can't, then write the file to the ApplicationData directory or the ProgramData (Application Data for all users on Windows XP) directory.
The Windows event log is definitely the way to go for logging of errors. You're not limited to the "Application" log as it's possible to create a new log target (e.g. "My Application"). That may need to be done as part of setup as I'm not sure if it requires administrative privileges or not. There's a Microsoft example in C# at http://support.microsoft.com/kb/307024.
Windows 2008 also has Event Log Forwarding which can be quite handy with server applications.
I agree with Lou on this, but I prefer to set this up in a configuration file like Joe said. You can use
file value="${APPDATA}/Test/log-file.txt"
("Test" could be whatever you want, or removed entirely) in the configuration file, which causes the log file to be written to "/Documents and Settings/LoginUser/Application
Data/Test" on Windows XP and to "/Users/LoginUser/AppData/Roaming/Test on Windows Vista.
I am just adding this as I just spent way too much time figuring how to make this work on Windows Vista...
This works as-is with Windows applications. To use logging in web applications, I found Phil Haack's blog entry on this to be a great resource:
http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx
%TEMP% is always a good location for logs I find.
Going against the grain here - it depends on what you need to do. Sometimes you need to manipulate the results, so log.txt is the way to go. It's simple, mutable, and easy to search.
Take an example from Joel. Fogbugz will send a log / dump of error messages via http to their server. You could do the same and not have to worry about the user's access rights on their drive.
I personally don't like to use the Windows Event Log where I am right now because we do not have access to the production servers, so that would mean that we would need to request access every time we wanted to look at the errors. It is not a speedy process unfortunately, so your troubleshooting is completely haulted by waiting for someone else. I also don't like that they kind of get lost within the ones from other applications. Sure you can sort, but it's just a bit of a nucance scrolling down. What you use will end up being a combination of personal preference coupled along with limitations of the enviroment you are working in. (log file, event log, or database)
Put it in the directory of the application. The users will need access to the folder to run and execute the application, and you can check write access on application startup.
The event log is a pain to use for troubleshooting, but you should still post significant errors there.
EDIT - You should look into the MS Application Blocks for logging if you are using .NET. They really make life easy.
Jeez Karma-killers. Next time I won't even offer a suggestion when the poster puts up an incomplete post.
I have an SQL Server database where I have the data and log files stored on an external USB drive. I switch the external drive between my main development machine in my office and my laptop when not in my office. I am trying to use sp_detach_db and sp_attach_db when moving between desktop and laptop machines. I find that this works OK on the desktop - I can detach and reattach the database there no problems. But on the laptop I cannot reattach the database (the database was actually originally created on the laptop and the first detach happened there). When I try to reattach on the laptop I get the following error:
Unable to open the physical file "p:\SQLData\AppManager.mdf". Operating system error 5: "5(error not found)"
I find a lot of references to this error all stating that it is a permissions issue. So I went down this path and made sure that the SQL Server service account has appropriate permissions. I have also created a new database on this same path and been able to succesfully detach and reattach it. So I am confident permissions is not the issue.
Further investigation reveals that I cannot rename, copy or move the data files as Windows thinks they are locked - even when the SQL Server service is stopped. Process Explorer does not show up any process locking the files.
How can I find out what is locking the files and unlock them.
I have verified that the databases do not show up in SSMS - so SQL Server does not still think they exist.
Update 18/09/2008
I have tried all of the suggested answers to date with no success. However trying these suggestions has helped to clarify the situation. I can verify the following:
I can successfully detach and reattach the database only when the external drive is attached to the server that a copy of the database is restored to - effectively the server where the database is "created" - lets call this the "Source Server".
I can move, copy or rename the data and log files, after detaching the database, while the external drive is still attached to the Source Server.
As soon as I move the external drive to another machine the data and log files are "locked", although the 2 tools that I have tried - Process Explorer and Unlocker, both find no locking handles attached to the files.
NB. After detaching the database I tried both stopping the SQL Server service and shutting down the Source Server prior to moving the external drive - still with no success.
So at this stage all that I can do to move data between desktop and laptop is to make a backup of the data onto the external drive, move the external drive, restore the data from the backup. Works OK but takes a bit more time as the database is a reasonable size (1gb). Anyway this is the only choice I have at this stage even though I was trying to avoid having to go down this path.
Crazy as it sounds, did you try manually granting yourself perms on the files via right-click / properties / security? I think SQL Server 2005 will set permissions on a detached file exclusively to the principal that did the detach (maybe your account, maybe the account under which the SQL Server service runs) and no-one else can manipulate the file. To get around this I have had to manually grant myself file permissions on MDF and LDF files before moving or deleting them. See also blog post at onupdatecascade.com
Can you copy the files? I'd be curious to know if you can copy the files to your laptop and then attach them there. I would guess it is some kind of permissions error also, but it sounds like you've done the work to fix this.
Are there any attributes on the file?
Update: If you can't copy the files then something must be locking them. I would check out Unlocker which I haven't tried but sounds like a good starting point. You might also try taking ownership of the files under the file permissions.
When you are in Enterprise Manager or SSMS, can you see the name of the database that you are talking about? There might be a leftover database in a funky state. I'd make sure that you have a backup or a copy of the mdf somewhere safe. If this is the case, maybe try dropping the database and then re-attaching it.
I would try backing up the database on the desktop, and then see if it will restore successfully on the laptop. Doesn't explain your issue but at least you can move forward.
Run sqlservr.exe in debug mode with the /c switch and see what happens starting up. Any locking or permissions issue can be put to bed by making a copy of the file and transfering the copy to the origional.
Also check the associated log file (.ldf) .. If that file is missing or unavaliable you will not be able to mount the database to any sane/consistant state without resorting to emergency bypass mode.
I've had a similar issue. Nothing seemed to resolve it - even tried to reboot the machine completely, restarting SQL services etc. ProcMon and ProcessExplorer were showing nothing so I figured - the "lock" is done by OS.
I resolved it by DELETING the file and restoring it back from the drive mounted under another drive letter.
PS. My database file was not on a USB drive, but on a TrueCrypt-drive (in some you can say it's a "removable drive" as well)
Within SQL Server Configuration Manager, look in SQL Server Services. For all your SQL Server instances, look at which account is selected in the Log On Tab - Log On As:. I've found for instance, changing it to the Local System account resolves the issue you've had. It was the only thing that actually worked for me - and certainly, no shortage of people have had the same problem.
It's a security issue on -file level security - you have detached db with different credential and attaching it with other credential - just browse the article http://www.sqlservermanagementstudio.net/2013/12/troubleshooting-with-attaching-and.html
And try copy pasting it to different location.
I solved similar issue by granting system administrator to all permissions:
right click > properties
security tab
in group or usernames click edit.
click add > advanced
click find now to list all available permissions.
choose administrator and add it to list.
grant it to has full permission.
I had the same issue. Someone had detached the files and left, and we were unable to move it to another drive. But after taking ownership of the file (security-->advanced-->take ownership to your login id), and then adding your login id to the security tab and giving access on the file, was able to move.