Now, there are plenty of places to find resources on this issue, because it’s quite common to have to do so.  My issue, was a little different, in that there were multiple layers of security (authentication and authorization) for me to access the files that were needed.  Here’s what the setup looked like:

Web Server -> WorkGroup -> Firewall -> Domain -> File Server -> Network Share -> SAN

As you can see, there are several issues are hand.  Not only do the accounts have to exist to allow for this communication (and an Administrator account is the only way to go), all sorts of permissions have to be valid for this to function (ie. Local Permissions within each OS on each Server, NTFS (file permissions) on each local server, Access permissions through the Firewall, Access permissions of Domain Resources, Local process level permissions, etc).  It was a nightmare, but I believe I figured it out.

There are a few things that needed to be done in this situation.  First, the permissions on the SAN needed to allow Administrators full control.  Additionally, the local user on the file server needed to have administrative privileges, to both the system and the SAN, thus allowing the network share.   Next, the firewall rules needed to allow file traffic (I can’t remember the SMB ports right now – and Windows needs netBios and something else to let file transfers go through, as well as authentication).  Finally, the Web Server local user needs admin rights.

To get this to work, I needed everything involved to run with elevated privileges, from IIS, to each thread in the application.  Since there was going to be a large amount of file movement, as well as resource and memory manipulation, it’s required.

Therefore, the admin credentials were inputted into IIS to map the network share from the Web Server to the File Server.  Next, I had to impersonate the admin user in each thread within the application, a pain, but the guide can be found via Google (if I have time, I’ll track them down again). Next, the machine.config needed to be modified to allow the ASP.NET process to run with the elevated permissions.  The web.config needs to be altered to allow impersonation with the credentials as well.

Now here’s the kicker, and something that’s not quite known but buried within Microsoft’s documentation.  For this to work (Work Group computer to authenticate to another computer) is to mirror the accounts (same username and password) on both servers (these are local accounts, not domain accounts – since the share was local on the server, the domain can be bypassed. If it were a domain resource, we would have to authenticate via NTLM to an Active Directory server, which would have been a bit more complicated).  This allows the hash sent from one system to another to be identical, and thus, you will authenticate (if you know the username and password on one workgroup computer, and it’s the same on another, chances are you’re who you say you are).

This took me a week to figure out, which was not enjoyable.  I hope this saves you some time.

Where is ASP.NET 3.5 on IIS ?

Most people on installing .NET 3.5 on the server “expect” an entry for  v3.5 under the ASP.NET version Tab in IIS manager. And not finding that entry start panicking. If you have been one of those read on. The more tech savvy folks try to run aspnet_regiis -i from the v3.5 framework folder… but even that is missing

That brings us to the question

What exactly is ASP.NET 3.5 ?

Take a look at the v3.5 framework folder you will not find most of the files needed for ASP.NET to run like aspnet_isapi.dll / aspnet_filter.dll / aspnet_regiis.exe / aspnet_regsql.exe…

The reason being .NET 3.5 is not a stand alone framework like v2.0 or v1.1 . It is just an extension of the 2.0 framework. The extension provides developers with new language features like Anonymous Types, Extension Methods, Lambda Expressions and of course LINQ …. and AJAX is now integrated … also you have a few new ASP.NET controls <asp:ListView>, <asp:LinqDataSource>, <asp:DataPager>

Will I get ASP.NET version 3.5 under the ASP.NET tab in IIS 6.0 ?

Nope. Because as far as IIS is concerned nothing has changed. The aspnet_isapi.dll from the version 2.0 folder will still handle the requests and there is no new ISAPI dll specific to version 3.5. So you don’t have to change any Script Mappings in IIS …just leave the web application pointing to v2.0 under the ASP.NET Tab. And this brings us to the next question

What exactly is the extension ?

For that if you have Visual Studio 2008 go ahead and create a Website targeting the .NET 3.5 framework. Then go to the Property Pages of the Website and select References. You will find an entry like this

And those four assembly references provide the new features of v3.5.  Here is a 10,000 ft view of the functionality implemented in these assemblies

System.Core – Provides namespaces like System.Linq, System.IO

System.Data.DataSetExtensions – LINQ to DataSet

System.Web.Extensions – AJAX

System.Xml.Linq – New XML API.. supports LINQ to XML

Do I have to configure anything manually ?

No. When you install the .NET 3.5 redistributable on the server it installs these assemblies in the GAC. And any website that refers to these assemblies can fetch them from the GAC so you do not have to configure anything manually. All you need to do is publish the content to a web application that is marked with ASP.NET v2.0

And now you should be thinking

The new language features should require a new compiler. How exactly is the new compiler used ?

The answer is your web.config file. When you create an ASP.NET 3.5 website in Visual Studio 2008 an entry is made in the web.config something like

<system.codedom>
  <compilers>
    <compiler language="c#;cs;csharp" extension=".cs" warningLevel="4"
              type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <providerOption name="CompilerVersion" value="v3.5"/>
      <providerOption name="WarnAsError" value="false"/>
    </compiler>

The new features do require a new compiler to be used and the web.config tells .NET that the v3.5 compiler has to be used.

What about IIS 7.0 ?

IIS 7.0 is no different.

I found this great article regarding using SelfSSL (Self Signed Certificates).  The original document can be found here.  Virtual Server can be found here.

I followed the very easy instructions and it ran great.  Here is a shorter version of the directions and the links to get everything you need:

1. Download and install IIS 6.0 Resource kit: here
2. Open the IIS Manager (Start > Run > inetmgr), open the properties of the Virtual Server website (usually the 2nd one) (right click > Properties)
3. Change the SSL port to 1024 (default VS port) and change the TCP port to 1020 (or any other port number) > Apply
4. Open a command promt (Start > Run > cmd) and go to the SelfSSL director (/program files/iis resources/selfssl) and run the following command > selfssl /N:CN=<FQDN>/K:1024 /V:730 /S:2 /P:1024
   1. Where <FQDN> is the website domain name (ie. steve-oh.com, yahoo.com, etc) and /S:2 means the second site on the server.
5. Now browse to the Virtual Server website and install the certificate and you’re done!

Now you have a Secure Socket Layer (SSL) connection from any remote computer to your server at 1028 bit encryption, so you can rest easy when logging in over the internet.