Rick Barber's Blog

There are numerous issues that I have seen come up regarding IIS not working properly, and many of those are due to improper permissions.  Many of these issues can efficently be tracked down by using Event Viewer -> Security.  However, the default installation of Windows does not set everything needed to properly take advantage of this.  Here are some settings that I recommend changing which will make initial troubleshooting easier.

We are first going to change the Local Security Policy by enabling failures of some policies.  Go to Administrative Tools -> Local Security Policy.  When the Local Security Settings window comes up, expand Local Policy and select Audit Policy.  Select the following three policies and check the box for Failure to log failures of those events:

Audit account logon events
Audit logon events
Audit object access

Next you also want to turn on auditing for all the partitions on the computer if you are using Windows Server.  To do that open up Windows Explorer, right click on a partition, and choose Properties.  Click the Security tab in the properties window, then click the Advanced button.  Select the Auditing tab in the Advanced Security Settings window, then click the Add button.  Enter everyone and click OK.  In the Auditing Entry dialogue box, check the Failed box on Full Control.  That will cause all the boxes in the Failed column to be checked.  Select ok all the way back out.  Now disk level auditing is enabled.

You can look for security issues first when you have problems and enough information should now be logged to better assist you.

I came across this today and wanted to share.  I have looked for this in the past with little success so maybe you will come across this post when you need it.  Sometimes you need the default password that was assigned to IUSR_MachineName and IWAM_MachineName from when you initially installed IIS.  That information is actually quite easy to get.

First make a copy of adsutil.vbs located in c:\inetpub\adminscripts, name it something else, and move it to a folder with locked down permissions:
copy c:\inetpub\adminscripts\adsutil.vbs c:\admin\adsutil_iispw.vbs

While you could certainly put the copy in the same location and delete it when you are done, I prefer to put it in a location that only administrators have access to so I can easily reference it in the future.  It all depends on what your best practice security measures are.

Next edit adsutil_iispw.vbs and go to line 2592.  It currently reads:

IsSecureProperty = True

Edit it so that it reads:

IsSecureProperty = False 

Save adsutil_iispw.vbs and close it.  Remember  that any time you are editing script files, config files, etc., you are best off using Notepad so that extra characters and formatting are not saved to the file which would prevent it from running properly.

Now you can run the following to get the IUSR password:

cscript c:\admin\adsutil_iispw.vbs get w3svc/anonymoususerpass

or the following to get the IWAM password:

cscript c:\admin\adsutil_iispw.vbs get w3svc/wamuserpass

I hope this helps when you need it!

I am working on a project right now that requires me to send multiple values to another page from a GridView.  The GridView control in ASP.Net 2.0 makes it easy to send a single value through the URL and it doesn't take very long searching the Internet to find many people who have provided this information.  I might add that it is part of the tooltip for the Gridview if you go through the settings of editing the columns in Visual Studio 2005.  There are also a multitude of suggestions from many people on passing multiple values but after I tried numerous options, I could not get any of them to work.  I did stumble across an article from Azam Sharp that finally got me going in the right direction:  http://www.gridviewguy.com/ArticleDetails.aspx?articleID=133.  While the fundamentals of my application use the foundation of Azam's article, the final product is different enough from the article to make me include it here.

 First we need to create a GridView with the columns that we need.  For better control we will need to use TemplateFields.

 <asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False">
    <Columns>
        <asp:TemplateField HeaderText="Field1">
            <ItemTemplate>
                <asp:HyperLink ID="hlField1" runat="server" NavigateUrl='<%# FormatUrl(Eval("Field1"),Eval("Field2"),Eval("Field3")) %>' Text='<%# Eval("Field1") %>'></asp:HyperLink>
            </ItemTemplate>
        </asp:TemplateField>
        <asp:TemplateField HeaderText="Field2">
            <ItemTemplate>
                <asp:Label ID="lblField2" runat="server" Text='<%# Eval("Field2") %>'></asp:Label>
            </ItemTemplate>
        </asp:TemplateField>
        <asp:TemplateField HeaderText="Field3">
            <ItemTemplate>
                <asp:Label ID="lblField3" runat="server" Text='<%# Eval("Field3") %>'></asp:Label>
            </ItemTemplate>
        </asp:TemplateField>
    </Columns>
</asp:GridView>

We also need to bind our data to the GridView.  In this specific case I am using an XML file.

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
    Dim oDs As New DataSet
    oDs.ReadXml(Request.PhysicalApplicationPath + "myFile.xml")
    GridView1.DataSource = oDs
    GridView1.DataBind()
End Sub

You will notice in my GridView that I am calling a function, FormatURL. In this specific implementation it is accepting 3 values that it will build into the string that it returns.

Public Function FormatURL(ByVal str1 As String, ByVal str2 As String, ByVal str3 As String) As String
    Return "pagedetail.aspx?id1=" & str1 & "&id2=" & str2 & "&id3=" & str3
End Function

The only thing left to do is to retrieve the querystrings on the new page, pagedetail.aspx in this case.

Dim str1 As String = Request.QueryString("id1")
Dim str2 As String = Request.QueryString("id2")
Dim str3 As String = Request.QueryString("id3")

As you can see, with this basic outline, there is tremendous power in the GridView and what you can do with it using a minimal amount of coding.

The other day I came across something out of the ordinary.  After some major configuration changes to the server after a reboot it lost network connectivity.  After looking at the server from the console, the Local Area Connection was missing from Network Connections and I couldn't connect to it through RDC.  Checking system event viewer gave some information:

 4292 - The IPSec driver has entered Block mode. IPSec will discard all inbound and outbound TCP/IP network traffic that is not permitted by boot-time IPSec Policy exemptions. User Action: To restore full unsecured TCP/IP connectivity, disable the IPSec services, and then restart the computer.

32777 - The LSA was unable to register its RPC interface over the TCP/IP interface. Please make sure that the protocol is properly installed.

12291 - SAM failed to start the TCP/IP or SPX/IPX listening thread.

Well I took the advice of the first error, disabled the IPSec service, rebooted the server, and voila!  I was able to connect to the server.  However Local Area Connection was still not showing in Network Connections.  After some digging I found a solution:

Solution:  (This involves a direct registry edit.  Be very careful with changes that you make because incorrect changes could make your system unstable or inoperable) 

Go into services and find Remote Procedure Call (RPC) Service.  Change the account that it runs under to a Local System Account.

Open registry editor (regedit from a command prompt) and backup the following keys:

As I'm sure you know, WPF/E is a client side technology.  However there are still come settings that need to be changed at the server level for WPF/E to work properly on your site. 

1. Change content expiration to 1 minute
2. Add some MIME types:
• .manifest - application/manifest
• .xaml - application/xaml+xml
• .application - application/x-ms-application
• .xbap - application/x-ms-xbap
• .deploy - application/octet-stream
• .xps - application/vnd.ms-xpsdocument

For more detailed instructions and information including a script to make these changes quickly check out this link:  http://msdn2.microsoft.com/en-us/library/ms752346.aspx

You may have noticed high CPU usage and sluggish performance on your server before.  When you fire up Task Manager you see numerous dw20.exe processes along with the other processes.  It doesn't take too much searching on the Internet to find that those are Dr. Watson processes creating dumps and forwarding them along to Microsoft behind the scenes.  The best way to immediately resolve this issue is to perform an IISReset.  That is only an immediate fix and won't prevent it from happening in the future. 

The first thing you should do on a production web server is to disable error reporting.  To do this, right click 'my computer' and choose 'properties.'  Click on the 'advanced' tab and choose the 'error reporting' button.  From that screen you can choose the radio button to disable error reporting.  You should check the box to notify you when a critical error occurs.    

While I am talking about performance it is also a good opportunity to mention that your production site should be using 'debug="False"' in the web.config.  It can have a significant negative impact on your application as well as the server.  Here is a link with some great information:   http://blogs.msdn.com/tess/archive/2006/04/13/575364.aspx

For the most part, web pages load sequentially where pieces of code execute one right after the other.  Sometimes you need a page to stop for a predetermined amount of time while it waits for other tasks to complete.  An example of this is a web page that sends an email outside of your network which needs to wait while the email is sent, processed by the spam filter, checked by the anti-virus, and then processed by the mail server to show up in a mail box before the web page indicates whether the message was received.  As you know, this process can take over 30 seconds. 

Before ASP.Net 2.0 it was possible to implement something like this, but it was either involved writing a bunch of code or using a third party component.  Now with ASP.Net 2.0 you can use the following:

System.Threading.Thread.Sleep(xxx)

This stops execution of the page for xxx number of milliseconds, so a value of 120000 would pause page execution for 2 minutes. 

One thing to keep in mind is that this only pauses execution of the page and has no affect on IIS values.  IIS is generallly set to timeout after two minutes so you will get a timeout error if you don't also adjust the value for the web site in IIS.  In my testing I've found that three minutes is about the maximum that you should consider doing this for.  If you need to do it for a longer time then you should try looking at the problem you are trying to solve from a different angle.

In today's world of graphical user interfaces, it's easy to forget about the good old days.  However if you do any administration you know how helpful it is to perform tasks from the command prompt.  It is very quick and easy to throw together a batch file that performs various tasks. 

So you don't remember any of those commands?  There is just one word you need to remember.  Help.  If you open up a command prompt and type help, it will display a list of commands that you have access to.  If you need more information on a particular command, such as Tree, just type Help Tree.  You will get a short description of the command followed by the syntax for the command.  Then there is a listing of all the switches and parameters with their descriptions.  For any old schoolers out there, you know that tree /? will also yield the same results as help tree.

This error is an issue that is often encounted, especially in shared hosting, and is due to a higher trust level in place on the shared hosting server in order to provide the best security to all the clients on the server.  In ASP.Net, a trust level defines what level of access your code has to the server.  Higher trust levels have more access to the server, while lower trust levels have less access providing more security between the separate applications. 

Often the application that was created and worked properly on your local development machine doesn't work when you upload it to the shared hosting server and will throw this error.  This is because most local development machine run in Full Trust allowing your ASP.Net application unrestricted access to the machine.  It can do read files and folders outside of its own root, access the registry, and even write to the Windows event log.

For obviously reasons a quality host will take steps to improve the security and stability of its shared servers and limit the access of each individual site.  It is fairly standard practice for shared hosting ASP.Net sites to be required to run under medium trust.  This does occasionally create some issues with executing certain code on the server but almost always there is a different way to accomplish the same task within the constraints of medium trust.

Here is a link with more information on the restrictions of medium trust and also how to configure a server for medium trust that should make it easy for you to setup a development environment that will match the medium trust environment of a shared host.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGHT000020.asp 

Like many people, I like using Microsoft's command line FTP utility.  It is especially good for automating in a batch file to transfer files to remote servers through a scheduled task.  Recently I ran into an issue with this.  Out of the blue the task stopped working.  After much digging I found that there is a limit on the size of the upload that the FTP utility can handle on Windows 2003 Server.  For some reason it can't handle files larger than 2 GB.

There are a couple of ways around this.  One way is to install a third party command line FTP that can handle larger FTP uploads, such as WS_FTP from Ipswitch.  If you don't want to install a third party program I also found another 'trick.'  It seems that the command line FTP for Windows XP doesn't have the 2 GB limitation.  I copied ftp.exe to the directory where the batch file was and modified the batch file to use the local directory copy instead of the one in %windir%/system32 and my automated uploads started working properly again.