For a dedicated server, is it better to store the connection string in web.config or machine.config? what's the advantages and disadvantages of each approach?
Thanks
Edit: I'm concerned about security here, so, the question is about which approach is more secure.
I would always go with web.config on the grounds that that is where everyone would expect it to be. There is no point in giving the person that has to maintain the web site any more difficulty by storing connection strings in an unusual place.
ADDITIONAL
Based on the additional information that the OP is interested in the security aspect, rather than and general reason I've added the following.
I still wouldn't store connection strings in the machine.config. If you do that any .NET application running on the machine has access to your connection strings.
web.config is a protected file. IIS won't serve it up by default unless you do something to misconfigure it.
I, personally, would never store my connection strings in my machine.config file, only ever in the web.config.
You say it's a dedicated server, but is this server dedicated to a single web application?
If not, you've now got a single file (machine.config) that's effectively sharing configuration data for multiple (probably un-related) web applications. Depending upon the number of those applications, and if you ever needed to move them to another server, using the machine.config could get very messy.
Even if the server is dedicated to a single web application, you'll probably be performing your development and testing on other machines. Since the machine.config is not normally a file that's included within the file-set of a ASP.NET web application project, you will probably have to go out of your way to deploy the machine.config to each of the various dev/test/production machines, and ensure that other (non-connection string) related configuration within them is correct for that machine.
Using the web.config to store database connection strings makes perfectly logical sense and is entirely expected by almost all ASP.NET developers, even if you have multiple applications that will use the exact same database on the exact same database server. Keeping this configuration in the web.config of each application allows each of those applications to be more self-contained and not reliant upon some other "outside" file.
I generally view the machine.config and something that the framework itself uses, and it belongs on a machine and is specific to that machine. I very rarely go in and touch it myself. I view the web.config as a file that's part and parcel of your web application project and "moves around" with that project as it moves and is deployed to different machines.
Also, don't forget that a lot of what's defined in the machine.config can be "overridden" on a per-application basis by redefining certain configuration elements within a specific application's web.config file.
Of course, there are a few valid reasons to editing/changing your machine.config file (such as multiple web servers in a web farm will probably need things like encryption/decryption keys within the machine.config to be synchronised), however, I don't believe database connection strings are one of those valid reasons.
security wise you could look into storing your connection strings in there own encrypted .config file that your web.config file would have a reference to.
If security is your primary concern, concentrate on locking down the database and user permissions. The security difference between web/machine .config is minimal. Colin's answer is correct. I'd have voted up or commented there but I don't have the moxie yet!