Tomas Aschan's questions

I have two servers running Windows Server 2003, and I want copy files from one server (A), programmatically with a windows service running under the Local System account, to a shared folder on the other (B). I keep getting "access denied" errors, and I can't figure out what security settings I need to set to open the shared folder for writing.

This is what I've done on the recieving end:

1. On A, right-click on the folder to share, choose the tab "Sharing" and select "Share this folder". Set a share name.
2. Click "Permissions", add the group "Everyone" and give it full control.

I tried choosing the "Security" tab to give some permissions there as well, but the "Add" dialog only finds local users, despite the fact that B shows up in the "Workgroup computers" dialog. After further inspection, this is the case also for the "Permissions" dialog under the "Sharing" tab (are they the same?).

Update: I have done some further research, and found that the program on server A is run under the SYSTEM account. This is not something I dare change, because of the risk to break other things that this program also does (it's a build agent on our TeamCity CI server).

Thus, I need a way to give A\SYSTEM access to write in a shared folder on B, in a workgroup environment.

Update 2: I've now been able to do the following changes to my configuration:

• There is a user account on each server named TeamCity. They have the same passwords, and are both parts of their respective Administrators group (which I've verified by logging on via remote desktop to both servers using the same information).
• TeamCity (specifically \\B\TeamCity) has full control access to the shared folder on B.
• The build agent on A runs under the \\A\TeamCity account.

When I try to copy files this time, I get an error stating

Could not find part of the path '\\B\Shared.Folder.Name'

I can copy the path from the error message and paste it into the address bar in Windows Explorer when logged on to the TeamCity account via Remote Desktop, and explorer navigates to the shared folder on B.

I've been struggling for some time now to be able to use the built-in functions in Visual Studio 2008 to handle *.mdf database files with SQL Server 2008 Express. I'm running on an x64-based system, and I've read that there is a known problem with this setup, but the hotfix has not solved my problems.

Basically, what happens is that when I try to add a new *.mdf file to the App_Data folder of a project, I get an error message saying:

Connections to SQL Server files (*.mdf) require SQL Server Express 2005 to 
function properly.  Please verify the installation of the component or download 
from the URL:    http://go.microsoft.com/fwlink/?LinkId=49251

My (unsuccessful) steps to solve this:

1. Uninstall all possible associated programs to Visual Studio, SQL Server or .NET Framework (which left .NET 2.0 Compact Framework and .NET 3.5 Compact Framework, and nothing else .NET related, installed).
2. Reboot.
3. Install .NET 3.5 SP1, SQL Server 2008 Express and SQL Server Management Studio 2008 Express via the Web Platform Installer 2.0 (Beta).
4. Reboot.
5. Install Visual Studio 2008 Professional from disc.
6. Reboot.
7. Install Visual Studio 2008 Service Pack 1.
8. Reboot.
9. Install hotfix.
10. Reboot.
11. Start VS, create new Web site and try to add database. Still get the error message...

When I look in the Help/About dialog, the hotfix shows up among applied updates. I have also checked and double-checked that the SQL Server instance name is correctly set in Visual Studio (I copy-pasted the instance name from the login screen in SSMS).

Why does the hotfix not solve my problems? Am I doing things in the wrong order, or do I have the wrong software versions somewhere?

According to the KB article, the problem is that Visual Studio doesn't correctly detect "some registry keys" - but nothing is said about which keys. Does anyone know how to fix this manually?

Oh, and yes - I've seen this post. I know I could just "downgrade" to the x86 version of SQL Server, but I really want to make this work with the x64 version (if nothing else, just because it's supposed to work...), so that solution doesn't really solve my problems. Please don't close this as a duplicate.