Alex Chang

A fix for when Visual Studio .NET is slow in starting up/opening

One of our developers had been suffering from extremely slow load/start-up time with the Visual Studio .NET 2003 on his developement machine (it took more than 1 minute to get through the splash screen). He tried uninstalling and re-installing VS.NET, but the problem still persisted. So today, I set out to find a solution. After about an hour of googling and searching on the web, forums, blogs, and newsgroups (it seems that there aren't that many mentionings of this issue out there), I finally came across a posting that lead us to the fix:
http://dotnetjunkies.com/Newsgroups/microsoft.public.vsnet.ide/2004/3/29/97325.aspx

What caught my eye was that, as mentioned in this newsgroup posting, we also noticed that the slow start-up problem only occurred when the developer's workstation was connected to the network. Visual Studio.NET would load without delay when we disconnected the network cable from his machine. The newsgroup posting pointed out that this is an issue with the MRU list (Most Recently Used list). We think that our developer may have tried to access/open a solution or a project across the network some time in the past. So Visual Studio.NET must've cached the file references in its Most Recently Used list. So everytime the Visual Studio.NET launched, it may have been trying to find those files on the network (which may no longer have existed). The recommended fix was to set the number of the display items in most recently used list to 1 (1 is the minimum number, default is 4 I believe) from the Tools->Option menu to clear the MRU list. However, after setting the MRU list to only display one item, the problem still remained! After further searching on "Visual Studio .NET MRU list", I found one of the Developer PowerToys (http://www.gotdotnet.com/team/ide/) called VSTweak. This nifty tool has a MRU Lists Manager that allows you to clear recent files and projects. After clearing out the MRU lists, the Visual Studio .NET launched in a heartbeat without any delay. Woo hoo!

Hope this is of help for some developers out there.

How to use Trusted Connection when SQL server and web Server are on two separate machines

Recently, in our consideration to make the production server environment more secure, one of the things we looked into was securing the database connection information between the web server and SQL server. I received much help from attending DevDays 2004 and also from doing some research on the Internet on this matter. There are some options when it comes to securing the connection string between a database server and a web server. I'll just list a few here:

Use a trusted connection with integrated authentication.
Use the Aspnet_setreg.exe utility to encrypt the connection string and store it in the registry. You can refer to these two articles for detailed instructions on how to do this: http://support.microsoft.com/default.aspx?scid=kb;EN-US;329290 and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT11.asp
Using DPAPI (Data Protection application programming interface) to secure the connection string. You can refer to these articles: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT08.asp and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/windataprotection-dpapi.asp and http://www.codeproject.com/system/protected_data.asp

In this blog, I'll focus more on option 1 - using a trusted connection. You see, it's very straightforward to configure a trusted connection when the SQL server and web server are on the same machine. For Windows 2000 Server or XP Pro machines, you just need to make sure the local “ASPNET” account (under which ASP.NET application runs) has appropriate access to the database that your application will be using. For Windows Server 2003, you need to make sure that the “Network Services” account (or “IIS_WPG” group – of which the “Network Services” is a member) has the appropriate access to the database. You can follow a step-by-step procedure to configure this here: http://www.asp.net/faq/AspNetAndIIS6.aspx#4 (under the section titled “Supporting integrated authentication with SQL Server”).

The problem arises, however, when the database server and the web server are on two separate machines (assuming they are on the same network). The issue lies in the fact that the local accounts/credentials (“ASPNET” in Windows 2000 Server and Windows XP Pro., “Network Services” in Windows Server 2003) under which ASP.NET worker process runs are local accounts (local to the web server). Therefore the database server on a separate machine will not be able to see/recognize these accounts. So if you try using the same steps mentioned above to configure a trusted connection between the web server and the SQL server, you will most likely see an error message such as “Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.” , when you try to launch your ASP.NET application.

One solution is to set up a domain account with minimal access (the same level of access as the local “ASPNET” or “Network Services” account on the web server) and grant this account the appropriate access to the database on the SQL server that your web application will be accessing. Then, you can use impersonation to make your ASP.NET application run under the domain account that you just created. (Does anyone know of a way to set up the trusted connection without impersonation? I would very much like to know how we can avoid using impersonation and any overhead associated with it. Some postings mentioned making the local accounts “ASPNET” or “Network Services” on both servers to have the same password, but I don’t think this is a good solution). Here are some tips/steps on using impersonation for trusted connection with a domain account:

When creating the domain account, make sure it has the proper level of access to run ASP.NET applications. You can refer to this page for a list of directories and the permissions that this domain account must have to them. For security purposes, don't give this domain account any more permission than you have to.
Assign the domain account the necessary permission to the database (you can still follow the instructions at http://www.asp.net/faq/AspNetAndIIS6.aspx#4. Just make sure you choose the domain account that you just created).
In order to turn on impersonation, there are two options:
- In the web.config file of your application, add the following line: <identity impersonate="true" userName="domain\user" password="password" /> (put it somewhere between the <system.web></system.web> tags) However this really defeats the purpose of using the trusted connection to avoid having to include the credential and the password in the connection string. If you use this method, you will still need to encrypt the credential and the password in order to keep this information safe.
- (This is the better method in my opinion) In the web.config file, add the following: <identity impersonate="true" /> (this time without the user name and password). Then, from IIS Manager, right click on the virtual directory assigned to your application and select “Properties”. Click on the “Directory Security” tab, then under “Anonymous access and authentication control” click “Edit”. If you are going to allow anonymous access to the application (not requiring users to login with windows authentication each time they access this web application), make sure “Anonymous access” checkbox IS checked. Then uncheck “Allow IIS to control password”. In the “User Name” field, type in (or you can browse to) the domain account (domain\user) and type in the password for the domain account in the “Password” field (By default IIS uses IUSR_machinename for the anonymous account, you can refer to this page if you would like to find its default password in case you want to change it back later for some reason) . Then under “Authenticated Access”, make sure NONE of the boxes are checked. Press “OK” and “OK” to save the settings and exit IIS.
Then in web.config you can use either one of these connection strings:
- "data source=yourservername;initial catalog=databasename;Integrated Security=SSPI"
- "server=yourservername; database=databasename;Trusted_Connection=true"

Hopefully, by using the tips and steps above, you should be able to get the trusted connection to work between the SQL server and the web server.

I hope this long-winded blog will be helpful to some. I don’t claim to be an expert in this, so as I mentioned earlier, if anyone has a better solution for configuring the trusted connection, I am all ears. I really would like to know if there is anyway to use trusted connection without impersonation.

Here are also some good references/discussions related to this topic:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbtskaccessingsqlserverusingmappedwindowsdomainuser.asp http://weblogs.asp.net/cschittko/archive/2004/03/05/85035.aspx http://support.microsoft.com/default.aspx?kbid=316989 http://dotnetjunkies.com/Newsgroups/microsoft.public.dotnet.framework.aspnet.security/2004/3/22/75451.aspx http://dotnetjunkies.com/Newsgroups/microsoft.public.dotnet.framework.aspnet.security/2004/3/22/74067.aspx http://www.winnetmag.com/Article/ArticleID/9002/9002.html http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetAP05.asp http://www.kamath.com/tutorials/tut002_iisanon.asp http://www.microsoft.com/technet/community/columns/insider/iisi0102.mspx#XSLTsection124121120120

Update: Frans Bouma mentioned that running web server on a domain may not be according to Microsoft's best practice for security. Could someone confirm this? Is there a better way then to configure a trusted connection when IIS and SQL server are on separate machines without the use of impersonation?

Installing Sharepoint Services (WSS) on a sub-domain - Part II

Continuing from my last blog (It should've really been titled “Installing Sharepoint Services on a sub-domain” to avoid any confusion that this may be a solution to a Project Server 2003 installation problem. So I am renaming the title here.) In part I of this blog, I posted some steps that we went through in preparing our DNS server and IIS for setting up a subdomain for the Windows Sharepoint Services. So here are the rest of the steps for the actual installation of the WSS with the DNS Server and IIS settings that we configured in Part I:

Click on the WSS installation File (STSV2.EXE). You can download it from here.
Read and check "I accept the terms in the License Agreement". If agree, click "Next"
Choose "Server Farm" installation, click "Next". At the next window, Click "Install"
After the installer finishes, you should see the IIS restarting
After IIS has restarted, the "Configure Administratrive Virtual Server" window will come up.
At the Application Pool section, Select "Use an existing application pool", then at the dropdown list, select "StsAdminAppPool(NT AUTHORITY\NETWORK SERVICE)" (This application pool was created during the installation). At the bottom of the page, click "OK".
When you see the "Application Pool Changed" page, open a command prompt window and enter "iisreset". After IIS has been restarted, click "OK" on this page.
At the "Set Configuration Database Server" page, under "Configuration Database" section, provide the name for the database server, and for "SQL Server database name:", put WSSDB. check "Use Windows Authentication" (You can use a SQL connection user name and password if you can't use the trusted connection for the SQL server.)
Make sure "Connect to existing Configuration" is un-checked. Under the "Active Directory Account Creation" page, select "Users already have domain accounts, Do not create active directory accounts". click "Ok"
You should now see the "Central Administration" page, Under "Virtual Server Configuration", click on Extend or upgrade virtual server.
At the "Virtual Server List" page, click on the one that you created for sharepoint services (e.g. http://sharepoint.mydomain.com with the name "Windows Sharepoint Services") If you don't see your virtual server listed, click on the "complete list" at the top.
At the Extend Virtual Server page, under Provisioning Options, click on "Extend and create a content database")
At the "Extend and Create Content Database" page, under the "Application Pool" section, click "Create a new application pool". Under "Application pool name:" type in "Sharepoint".
Under "Select a security account for this application", select "Predefined" and select "Network Service" in the dropdown list.
Under the "Site Owner" section, provide an email of the site owner at the "E-mail" field. (e.g. sharepoint@mydomain.com)
Leave everything else as default, and click "OK" at the bottom of the page.
You should see now the "Operation in Progress" page, with a turning-gear icon and "Please wait while your changes are processed" message.
After it finishes with the new settings, you should see the "Virtual Server Successfully Extended" page. and the message: "New top-level Web site URL: http://sharepoint.mydomain.com". Click OK at the page. You should be redirected to the "Virtual Server Settings" page. You may close the browse at this point.

And that's it! You should've succesfully installed Windows Sharepoint Services on a subdomain.

If you are going on from here to install Project Server 2003, just following this Project Server 2003 Installation Guide. At the end of chapter 5 of this installation guide, it shows you how to run the Windows SharePoint Services Configuration Wizard that comes with Project Server 2003 in order to intergrate Project Server with WSS. Chapter 6 shows you how to configure the database and Chapter 7 takes you through the rest of installation process for Project Server 2003.

Installing Sharepoint Services (WSS) with Project Server 2003 - Part I

Recently, we purchased Project Server 2003 with the view to improve the various project management tasks and activities that we have at the non-profit organization where I work. Two weeks ago, I slated some time to install it on one of our servers running Windows 2K3. We chose also to install Windows Sharepoint Services (WSS) with Project Server in order to take advantage of the document collaboration and the issue tracking features that WSS has to offer. Overall, the installation process was pretty straightforward. The Project Server 2003 Installation Guide and this Project 2003 book that we have both give very detailed step-by-step instructions for the installation. After completing the installation however, we soon discovered that with the Sharepoint Services installed, we had a difficult time running other web applications and web pages that were already on the server before the installation. We kept getting the 404 File not found error (and sometimes also the 403 access forbidden error). After some research on the web, we found out that WSS has some custom HttpHandlers that intercept all the browser requests through its ISAPI filter (I just found an excellent blog post explaining this behavior and this knowledge base article also addresses this issue) In order to allow the pre-existing web applications to work, you have to tell WSS to exclude the paths to the IIS virtual directories hosting your other web applications when it’s handling all the incoming URLs. You can configure the excluded paths in the Sharepoint Central Administration under Administration Tools (the detailed steps are outlined in the KB article and also mentioned in Maxim’s article). However, I was not able to add the root directory of the web server in the excluded path. Even though in Sharepoint Central’s Administration tool, under the “Add a new path” section, it says “Note: To indicate the root path for this virtual server, type a slash (/).”, it kept throwing an error when I tried adding the root path. So if you need to have a web application/web site running at the root directory of your wwwroot, you may be pulling your hair out at this point. We also found that we were not able to install/run Vault server on the same machine when Sharepoint Services is installed (even after we excluded the paths in WSS to Vault’s virtual directories). After a few hours of trying different configurations in IIS (application pools, permissions...etc), we finally gave up. I then came across this article where Robert advised to install WSS on a separate DNS Sub-domain (e.g. http://sharepoint.mydomain.com) to avoid all the problems that I just mentioned (see Tip#2 under Configuration in Robert’s article). We gave that a try with the following steps (sorry for the verboseness for those who already know how to do this like the back of their hand):

In the DNS management console running on the domain controller (or wherever you are running the DNS Server), expand the Forward Lookup Zones folder, right click on the desired domain and select “New Host (A)”.
In the “New Host” window, put “sharepoint” as the new host name and also the IP address of the server where WSS is to be installed. Click “Add Host”.
From IIS 6 manager on the server where you plan to install Sharepoint Services, expand the server (local computer) tree, then right click on the “Web Sites” folder. Select “New” and then “Web Site…”.
When the website creation wizard comes up, put “Sharepoint Services” for description, clicked “Next”. Under “Host header for this Web site (Default None):”, put the sub-domain name for the WSS (in this example: sharepoint.mydomain.com). Leave IP address as “(All Unassigned)” and TCP port as “80”, click “Next”. Under “Enter the path to your home directory”, provide a path (e.g. C:\Inetpub\wss If the directory hasn’t been created, create it now) to where the Sharepoint files will be stored when you extend the virtual server in WSS. Click “Next” and then “Next” again. Then you are done preparing the DNS and IIS.

If you are running IIS 5 on a Windows 2000 Server, you can refer to this article on how to set up subdomains. If you don’t have a DNS server, you can add an entry in the hosts file in your \winnt(or windows)\system32\drivers\etc directory: 127.0.0.1 Sharepoint.mydomain.com

(Note: instead of 127.0.0.1, you can also use the actual LAN IP address of the server where WSS is to be installed).

If you are running IIS 5 on Windows XP Professional, you could find some help in this article (also here).

In order to avoid making this too long-winded (I think it's too late :) ), in part II of this blog, we'll go over the detailed steps of installing Windows Sharepoint Services with the DNS and IIS configurations that we just made.

Hope someone will find this helpful.

Blog Debut

Thanks to Donny Mack and the Dotnetjunkies, I've been given a blog space here. So this marks the beginning of my blog journey. :)

A brief note about myself: I've been in web development since 2000, working with various web technologies such as ASP, PHP, and ASP.NET. For the past year and half, I've been focusing mainly on building applications with ASP.NET. Currently I'm working as a team lead/IT manager at a non-profit organization. I've received a great amount of help from the ASP.NET community through various weblogs, so now I hope I can contribute something helpful back to the community.

Here are some of the things that I would like to blog about:

1. Various tips and helpful solutions that we have found and gathered in developing applications with ASP.NET 1.1 (a lot of hard-learned lessons :) )

2. Our experience of studying/testing what Whidbey has to offer (just received the alpha bit from attending the DevDay this past Monday).

3. Our experience of working with Rainbow Portal for our intranet development.

4. Working with Sharepoint Services and Project Server 2003.

Glad to be here.