July, 2007

July, 2007

  • Care, Share and Grow!

    Unable to see the Project/Web Site link in the Start Page of Visual Studio 2005

    • 1 Comments

     

    I remember I had worked with a customer on a support incident long way back wherein VS 2005 was not displaying links for Open and Create for Projects and Websites as shown in the screenshot below:


    In Visual Studio 2005 we were unable to see the Web Site or the Project link in the Start Page as shown below:

    Open:    Project... | Web Site...... }

    Create:  Project... | Web Site...... }

    The links were not getting displayed in Visual Studio 2005, although Customer had created multiple Websites and projects through VS 2005.

    -- Finally we figured out that there is a set of registry entries which contains the values for the Start Page of the VS2005.
    HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\Start Page
    -- I compared the Registry values on the customer's box with mine and found that in the above Registry hive, all the MRUCommand<n>GUID, where <n> == 1, 2, 3, 4 were set to 0 on customer's box unlike that of mine.
    Also MRUCommand<n>ID, where <n> == 1,2,3,4 were set to 0 on customer's box.

    We took a backup of the registry Keys, and manually modified the above keys from a working instance of VS 2005 on a different machine:
    All the values within () are in Decimal.
                            

    Name/Value                                                                                                                                  Type                         

    DownloadState      (1)                                                                                                      (REG_DWORD)
    MRUCommand1GUID    {5EFC7975-14BC-11CF-9B2B-00AA00573819}                                        (REG_SZ)
    MRUCommand1ID   (216)                                                                                                   (REG_DWORD)
    MRUCommand2GUID    {5EFC7975-14BC-11CF-9B2B-00AA00573819}                                        (REG_SZ)
    MRUCommand2ID   (321)                                                                                                   (REG_DWORD)
    MRUCommand3GUID    {C7547851-4E3A-4E5B-9173-FA6E9C8BD82C}                                        (REG_SZ)
    MRUCommand3ID   (43)                                                                                                     (REG_DWORD)
    MRUCommand4GUID    {C7547851-4E3A-4E5B-9173-FA6E9C8BD82C}                                         (REG_SZ)
    MRUCommand4ID   (44)                                                                                                     (REG_DWORD)

    Something like this:


    -- Closed the VS 2005 and reopened it and voila, it had the links for the "Web site..."  and "Project..." as desired.

    I did some research and found that this article will also be handy for any customizations in VS 2005

     http://support.microsoft.com/kb/320851

    Hope this helps!

  • Care, Share and Grow!

    IE, Office 2003 and Office 2007 behavior to save a file with characters like []

    • 0 Comments

    Recently I came across an issue where one of our customers wanted to open a file from the website and, when they get an Open/Save pop up they should click on Open and then once the file is open in Microsoft Excel 2003, should be able to save it with the original name as provided in the code.

    Here is the code they were using:

    Default.aspx

    <%@ Page Language="C#" AutoEventWireup='true' %>
    <html>

    <script runat='server'>
    protected void Page_Load(object sender, EventArgs e)
    {
    Response.Clear();
    Response.ClearHeaders();
    Response.ClearContent();

    Response.Buffer = true;
    Response.ContentType = "application/vnd.ms-excel";
    Response.AppendHeader("Content-Disposition", "attachment; filename=filename1.csv");

    Response.Write("a,b,c,d\n1,2,3,4\n");
    Response.End();
    }
    </script>
    </html>

    Now here is the problem. We are able to open the file in Excel 2003. Now once the file is open and if you try to save this file by clicking on File->Save/Save As, you will get an error (provided you don't remove the special character like "[" in the filename).

    Here are the screenshots when I access the page.

     

    Fig 1

    I click on Open. Now once the Excel file is open, try to save it without changing the name (you can change the location though)

    Fig 2

    So you see the file cannot be saved because it contains the character "[]" in it. The name that it will try to save is filename1[1].csv.

    This happens because IE stores the file on the client machine in the location C:\Documents and Settings\<profile>\Local Settings\Temporary Internet Files\Content.IE5\5N4G3UBL (some random value). The filename will be filename1[1].csv. IE automatically adds a version subscript by default.

    If you try to access the same page from a machine which has Microsoft Office 2007, you will not encounter this issue. Reason being that Office 2007 is modified to use a parentheses ("( )") instead of square brackets ("[ ]") while saving the file. And since parentheses is not a part of the above restricted set as in Fig 2 we can save the file.

    So as you see here, both IE and Microsoft Office 2003 are partially at faults. IE, because it adds the [] to the file name when saving it to temporary internet files folder and Microsoft Office 2003, because it cannot save a file with special characters like [ or ] in it. Office 2007 while saving the file uses parentheses and not square brackets. So there won't be a problem when client has  Microsoft Office 2007 installed.

  • Care, Share and Grow!

    Troubleshooting Anonymous authentication failures in IIS

    • 32 Comments

    Recently I was checking MSDN and KBs for a quick check on troubleshooting anonymous authentication, and sadly I could not find a single article devoted to it (that's strictly my personal experience). We often get calls on issues related to Anonymous authentication failures and this is something which I feel a user can fix oneself without requiring our support. My aim in this post is to ensure people have a good troubleshooting strategy for anonymous authentication failures.

    As with all my posts I won't get into much of concept building stuffs here on anonymous authentication in IIS; reason again being the same, you will find tonnes of articles on the Net talking about it and I don't want to be another one.

    So in brief Anonymous authentication in IIS is a type of access wherein any user can freely access the site. It's like a public website open to all.

     

    So let's get started....

    Anonymous authentication uses a local or domain account when user tries to access a webpage in IIS (By default it is of the form IUSR_<machinename>).

    All the webpages which have anonymous authentication will use an account in order to access a page, and depending upon whether the account has permission or not the page will be rendered. Typically if anonymous authentication fails, you will see 401.1 in the error page shown by IIS. This means that Anonymous user account for that page doesn't have necessary permissions to the page or else some other settings like Domain or local policy is restricting the access.

    If you have set only anonymous authentication for your web resource (that means no other authentication like Windows integrated or Basic ), and it fails then you will be shown 401.1 directly without any challenge which generally prompts to enter credentials.

    Wanna know how IIS negotiates an authentication, check this.

    If you want to check the anonymous username being used for a website or a virtual directory, type in this command at the following location:

    <Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/anonymoususername

    or,

    <Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/<Website Identifier>/Anonymoususername

    or,

    <Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/<Website Identifier>/<Virtual directory>/anonymoususername

    [If you get the result like: The parameter "anonymoususername" is not set at this node, it means it is inheriting the settings from its parent level.]

    If you want to check where all Anonymous username is set at a webserver level, you can type in:

    <Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs find anonymoususername

    Typically the Anonymous username is in the form of IUSR_<machinename>, wherein machinename is the server name.

    Although you can set it to a different value by manually changing it. It can be a local account to the server or a domain account.

    A caveat here, it's a security risk if you make anonymous username as part of an Administrator group (remember it allows access to everyone on the net without asking for credentials).

    To set an anonymous username at a website level, you can type in:

    <Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs set w3svc/anonymoususername <your desired username> (Remember to include quotes around the username). [This setting is at the global level, i.e. for all the websites in the server provided you don't manually override the settings at a specific website or Virtual directory level]

    or

    <Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs set w3svc/<Website Identifier>/anonymoususername <your desired username> [At a specific website level]

    or

    <Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs set w3svc/<Website Identifier>/<Virtual directory>/anonymoususername <your desired username>  [At a specific Virtual directory level in a specific website]

     

    I will move forward with specific issues one by one:

    Anonymous user account is locked out:

    Ensure that the account is not locked, disabled or expired.

    Password Synchronization issues:

    I have seen a lot of support calls (I mean a LOT) where password synchronization has been the issue, and this is very very simple to fix.

    Anonymous username's password are stored in two places in IIS 6.0: In the IIS metabase and in the SAM database.

    If the password at these places are not synchronized (not same), anonymous authentication will fail. They have to be same.

    So do this as the first step in troubleshooting:

    1) Find out how many places we have the anonymousername set by following the command I mentioned above. Here I mention it again:

    <Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs find anonymoususername

    2) If you have it set at multiple places, find out the specific site you are having problem with. Check the anonymous username for it and then check the password.

    <Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/<Website Identifier>/anonymoususerpass

    [You may find the password in encrypted format like ************. In such a case you need to modify the adsutil.vbs file to get the exact password. Open Adsutil.vbs in notepad from the above location and search for the function "IsSecureProperty(ObjectParameter,MachineName)".

    In this function IsSecureProperty(ObjectParameter,MachineName), you will find the following code:

     

    Function IsSecureProperty(ObjectParameter,MachineName)

    On Error Resume Next
    Dim PropObj,Attribute
    Set PropObj = GetObject("IIS://" & MachineName & "/schema/" & ObjectParameter)
    If (Err.Number <> 0) Then
    ReportError ()
    WScript.Echo "Error trying to get the property: " & err.number
    WScript.Quit (Err.Number)
    End If
    Attribute = PropObj.Secure
    If (Attribute = True) Then
    IsSecureProperty = True              <--------
    Else
    IsSecureProperty = False
    End If
    End Function

     

    In the highlighted line above, change the value to False, save and now rerun the adsutil.vbs command and you should see the actual password]

    or if you have it set at the global level only, check this:

    <Systemdrive>\Inetpub\Adminscripts>cscript.exe adsutil.vbs get w3svc/anonymoususerpass

    Copy the password from here and go to Computer management->System Tools->Local Users and Groups->Users

    You should find the username (By default, IUSR_<machinename> is used by IIS) [Unless you have Domain controller and Web server running on the same box. In such a case you need to look for the domain user name under Active Directory Users and Computers. I will talk about DC and IIS running on the same box later, this is really important!]

    Change the password for Username (or, IUSR_<machinename>), by pasting the password that you got from metabase.

    Ideally, if the issue was with Password synchronization your problem should get resolved at this point :) If not, then move on....

     

    NTFS permission for the requested web resource:

    NTFS permissions not set properly for the content can also cause 401.1 (although you should typically see 401.3 Access denied due to ACL). Ensure that the page we are trying to access has necessary NTFS permissions for Anonymous username (or the group that anonymous username belongs to). Ensure that Anonymous user account is part of the Users group.

    Policy settings:

    If your issue did not get resolved by Password synchronization, then Local security policy (or, Domain security policy) can be a very probable reason. Please follow the following articles religiously.

    Default permissions and user rights for IIS 6.0  (IIS 6.0)

    How to set required NTFS permissions and user rights for an IIS 5.0 Web server (IIS 5.x)

    Check this too.

    Error message when you try to view a Web site that is hosted on Internet Information Server 6.0 by using anonymous access: "401.1 Unauthorized: Logon failed"

    Typical reasons being:

    - Anonymous username being a part of Guests group (During IIS installation, IUSR_<machinename> is added to the Guests group by default), and Guests group being denied access to some web folders and/or denied access because of local/domain policy).

    Suggestion: Make sure that either you remove the anonymous username from the Guests group and/or remove the Anonymous username from any of the Deny policy settings (You can do this by going to the Local Security policy->Local Policies-> User rights assignment).

    - The account is corrupted because of some reason like corrupted SID, moving the server from one domain to another etc.

    Suggestion: First try adding the Anonymous username to the Administrators group to check whether you can access the web page or not. If it works it means it's an issue most likely with the permission for that account. If it still does not work, then there is some thing wrong..may be Policy settings or a corrupted account. Change the Anonymous user account to a different account and see if it works (be sure to make that account part of IIS_WPG group). If it works then it's a corrupted account. Recreate the IUSR and IWAM accounts (you can recreate by deleting existing IUSR_machine and IWAM _machine and then doing an IISRESET. IISRESET will recreate the IUSR and IWAM accounts for you) or manually creating a new user.

    - Check this The account that is used for anonymous access may be unexpectedly locked out in IIS 6.0 or in IIS 5.0

    At times you may see that HTML pages are running fine but not ASP pages. They might throw error like 401.3 etc. Check whether Users group has permission on ASP.dll at the <systemdrive>\wind*\system32\inetsrv folder.

    Account Lockout:

    Now something that creates confusion among a lot of people. At times people see their anonymous account getting locked intermittently and there seems to be no valid explanations for it.

    Scenario: You have set anonymous username at multiple levels in IIS.

    Let's say you have different usernames at the following level:

    Global Web Sites level  {IUSR_m1}

              Website 1   {IUSR_m2}

            VD1    {IUSR_m3}

            VD2    {IUSR_m2}

            VD3    {IUSR_m2}

     

    Website 2  {IUSR_m2}

    Now, let's assume you have different passwords at different levels. Now in the SAM database you can have only one instance of an account and hence only one password for it. Let's say you accidentally change the password for IUSR_m2 in the metabase at Website1 ->VD2 level and forget to change the password at the Website1, Website1->VD3 and/or Website2 level. Now since the password has to match in the SAM metabase too, only one of these will work. Also by mistake a wrong password can be set at a given level.

    1) If you changed IUSR_m2's password in the SAM database to reflect Website1->VD2, then Anonymous authentication works fine when you access a resource from Website1->VD2. Although now, anonymous authentication will fail when you access a resource from any of Website1, Website1->VD3 or Website2 levels.

    2) If you have the IUSR_m2's password in the SAM metabase reflecting the password set at any of Website1, Website1->VD3 and Website2 (assuming all of them have same password for simplicity sake), then anonymous authentication will succeed when you access a resource from any of the above levels, but will fail when you access a resource from Website1->VD2 level.

    Now most servers have an Account lockout policy after certain invalid logon attempts. So if users try to access the Web resources from different levels, at one point of time because of multiple attempts Anonymous user account will get locked out and this will block access from all the levels irrespective of the matching passwords in Metabase and SAM database.

    So IUSR_m2 might get locked intermittently because of the above scenario and will give unpredictable results. That's why I recommend to use a single Anonymous username at the global level only and let all the websites inherit from there,or else use completely distinct accounts at various levels (it again finally depends upon your requirement specific to the system).

     

    IIS and Domain Controller (DC) on the same server:

    Also, if your IIS server is a DC then you need to check:

    <Anonymous useraccount>-->Properties-->Account-->Logon Hours..., [Ensure we have Logon Hours permitted for the account]

    and <Anonymous useraccount>-->Properties-->Account-->Log On To..., [Ensure we have Logon to the machine enabled]

    Please keep this handy when you are troubleshooting issues on a DC for IIS authentication.

    Generally, DCs are very restricted when it comes to Permissions and access policies. Hence we have seen a lot of issues related to anonymous authentication failures on DCs. Microsoft recommends not to use a machine both as a DC and an IIS server from Security and Performance perspective.

Page 1 of 1 (3 items)