Monitor your entire network from a single platform. Free 30 Day Trial Now!
IIS 6 404.2 1260 error - Will not access files or directories with ".com" in the path name
Hoping the community can help me out. Have been tracking down an issue for 2 days and think I've narrowed it down to an IIS 404.2 1260 error but don't know how to fix.
First this used to work and has been working for 5+ years. The issue started sometime in the last 30 days. I've removed all MS updates over the last 45 days to see if that was the issue but the problem still exists.
This is on a W2K3 server with IIS 6. In the web service extentions the following are allowed... ASP, ASP .NET v 1.1.4322, ASP .NET v2.0.50727, PHP. All others listed are prohibited.
We have a client based application that posts and gets files from a webserver. The clients have a unique identification account name. The clients who used their email address as their account names are failing to get files. They can post files with no issues. Clients that don't have a ".com" in their account name are working fine for both post and get.
I enabled the ability to surf the directory structure via https based URLs. Walking the directory structure gives the same results as the client based application. Here are examples. For the ones listed as working I am able to access the directory and view the test.log file within the directory.
Works - https://mywebsite.com/bb/0/test@att-com/
Bad - https://mywebsite.com/bb/0/test@att.com/
Works - https://mywebsite.com/bb/0/test@att.com_/
Works - https://mywebsite.com/bb/0/test@att.net/
For the one that is bad I get the following msg in the browswer..
The page cannot be found
The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.
--------------------------
Within the IIS logs I get the following for the working test accounts..200 0 0....
2013-01-05 02:24:25 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/test@att-com/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+M
2013-01-05 02:24:31 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/test@att.com_/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+M
+Windows+NT+6.1;+WOW64;+Tr
2013-01-05 02:24:34 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/test@att.net/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+M
+NT+6.1;+WOW64;+Trident/4.
For the bad test account I get this in the iis log...404 2 1260....
2013-01-05 02:24:28 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/test@att.com/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+M
+Windows+NT+6.1;+WOW64;+Tr
For a production client that fails I get the same error in the iislog.....404 2 1260....
2013-01-05 02:00:40 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/22/20121206220628-inc5
I've tried to add .com as a new web svc extension and link it to the v2.0.50727/aspnet_isapi.dl
Help. I need some ideas for how to get this working again.
Thanks in advance for any support!!!
First this used to work and has been working for 5+ years. The issue started sometime in the last 30 days. I've removed all MS updates over the last 45 days to see if that was the issue but the problem still exists.
This is on a W2K3 server with IIS 6. In the web service extentions the following are allowed... ASP, ASP .NET v 1.1.4322, ASP .NET v2.0.50727, PHP. All others listed are prohibited.
We have a client based application that posts and gets files from a webserver. The clients have a unique identification account name. The clients who used their email address as their account names are failing to get files. They can post files with no issues. Clients that don't have a ".com" in their account name are working fine for both post and get.
I enabled the ability to surf the directory structure via https based URLs. Walking the directory structure gives the same results as the client based application. Here are examples. For the ones listed as working I am able to access the directory and view the test.log file within the directory.
Works - https://mywebsite.com/bb/0/test@att-com/
Bad - https://mywebsite.com/bb/0/test@att.com/
Works - https://mywebsite.com/bb/0/test@att.com_/
Works - https://mywebsite.com/bb/0/test@att.net/
For the one that is bad I get the following msg in the browswer..
The page cannot be found
The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.
--------------------------
Within the IIS logs I get the following for the working test accounts..200 0 0....
2013-01-05 02:24:25 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/test@att-com/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+M
2013-01-05 02:24:31 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/test@att.com_/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+M
+Windows+NT+6.1;+WOW64;+Tr
2013-01-05 02:24:34 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/test@att.net/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+M
+NT+6.1;+WOW64;+Trident/4.
For the bad test account I get this in the iis log...404 2 1260....
2013-01-05 02:24:28 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/0/test@att.com/ - 443 - X.X.X.82 HTTP/1.1 Mozilla/4.0+(compatible;+M
+Windows+NT+6.1;+WOW64;+Tr
For a production client that fails I get the same error in the iislog.....404 2 1260....
2013-01-05 02:00:40 W3SVC2018762905 WCIWS-001 X.X.X.101 GET /bb/22/20121206220628-inc5
I've tried to add .com as a new web svc extension and link it to the v2.0.50727/aspnet_isapi.dl
Help. I need some ideas for how to get this working again.
Thanks in advance for any support!!!
Who is Participating?
Do you have anti-virus on the server? I ask because it might think that '.com' is an attempt to do a redirect. And that might have happened during an anti-virus update.
Also does it work on the server itself?
Also does it work on the server itself?
Yes all the files can be accessed directly via windows explorer on the server and from another PC over the network.
There is currently no anti-virus on the server
There is currently no anti-virus on the server
These are identical!
xxx/bb/0/test@att.com is exactly the same...
does
Works - https://mywebsite.com/bb/0/test@att-com/
Bad - https://mywebsite.com/bb/0/test@att.com/
xxx/bb/0/test@att.com is exactly the same...
does
/bb/22/20121206220628-inc57-XXXXX@gmail.com/20121206220628-inc57-XXXXX@gmail.com.bum
I meant does that form of the URL with '.com' work internally in a browser at all. We've had some questions where a content filtering or external firewall device got updated and blocked things that weren't expected.
ve3ofa..
The first two are not identical. Slight difference is att-com .vs. att.com. The att-com url works but the att.com url fails.
Yes the file exists in your second question. I can look at it via explorer.
Dave - No the '.com' version does not work from a browser on the server and neither does one of the working test accounts...interesting Can't access either from a browser on the server. I am testing from a remote client PC and that can access all but the .com based accounts.
How do you check content filtering on the server? There are no external devices filtering.
The first two are not identical. Slight difference is att-com .vs. att.com. The att-com url works but the att.com url fails.
Yes the file exists in your second question. I can look at it via explorer.
Dave - No the '.com' version does not work from a browser on the server and neither does one of the working test accounts...interesting Can't access either from a browser on the server. I am testing from a remote client PC and that can access all but the .com based accounts.
How do you check content filtering on the server? There are no external devices filtering.
IE occasionally does some funny things to URLs. Can you use an alternate browser on the server to check the URL?
If run from a browser on the server.....
IE gives me - IE cannot disply the webpage
Firefox gives me - You are not authorized to view this page
From a PC accessing the website IE works except for the accounts with .com in their name
Would upgrading to .net 4 make any difference?
IE gives me - IE cannot disply the webpage
Firefox gives me - You are not authorized to view this page
From a PC accessing the website IE works except for the accounts with .com in their name
Would upgrading to .net 4 make any difference?
I doubt it. You need to use a network monitor like Wireshark to see what is actually being requested and responded. It's starting to sound like a problem with the server's response but you need to verify what being requested to make sure.
Can you create a different sub-directory with plain index.html that uses the same URL pattern but won't go thru your ASP.NET code? The purpose is to detect whether it is a server or code problem.
Can you create a different sub-directory with plain index.html that uses the same URL pattern but won't go thru your ASP.NET code? The purpose is to detect whether it is a server or code problem.
I created two test directories on each side of the webserver (http & https). These test directories are on the server in the top level wwwroot directory.
Results.
Works = http://192.168.1.101/test/
Works = http://192.168.1.101/test/test@att-com/
Works = http://192.168.1.101/test/test@att.com/
Works = https://192.168.1.101/test/
Works = https://192.168.1.101/test/test@att-com/
Bad = https://192.168.1.101/test/test@att.com/
This shows a similar behavior where the customers posting with ".com" in their account names fails. In previous posts I had not checked the simple test on the non-secure side of the site. Based on these tests it looks like the secure side is having the issue.
I loaded WireShark but don't know enough yet to see if it is showing the error of the https traffice in the logs. Will it show https errors or not?
Results.
Works = http://192.168.1.101/test/
Works = http://192.168.1.101/test/test@att-com/
Works = http://192.168.1.101/test/test@att.com/
Works = https://192.168.1.101/test/
Works = https://192.168.1.101/test/test@att-com/
Bad = https://192.168.1.101/test/test@att.com/
This shows a similar behavior where the customers posting with ".com" in their account names fails. In previous posts I had not checked the simple test on the non-secure side of the site. Based on these tests it looks like the secure side is having the issue.
I loaded WireShark but don't know enough yet to see if it is showing the error of the https traffice in the logs. Will it show https errors or not?
You have to tell Wireshark to show HTTPS info, it doesn't do it by default. It is probably a pain. http://wiki.wireshark.org/SSL
What error message do you get besides 404?
What error message do you get besides 404?
Already went thru that MS site. This is likely what is happening but I can't figure out how to make ".com" part of the authorized ISAPI. When I tried to add it as a mime type I got an error msg when I tried to save saying .com was already and authorized type.
Looking into wireshark
Thanks
Looking into wireshark
Thanks
You shouldn't be adding it as a MIME type, it's just part of the URL, not a file or file type of it's own. Do you have redirect code working on that server? Just one more place that it could be misidentified.
Also, have you tried a URL other than 'att.com'? Like http://192.168.1.101/test/test@google.com/
Also, have you tried a URL other than 'att.com'? Like http://192.168.1.101/test/test@google.com/
I tried the experiment on an IIS 7.0 server and it worked fine with both HTTP and HTTPS. I don't have access to an IIS6 server with HTTPS that I can try.
Yes same info in the logs 404 2 1260
Is there a way to reinstall a webserver on the same server and keep all the key settings?
Is there a way to export the settings so I could build a new one from scratch and then import the settings?
Is there a way to reinstall a webserver on the same server and keep all the key settings?
Is there a way to export the settings so I could build a new one from scratch and then import the settings?
I don't know the answers to those questions. I would not reinstall over your current web server since it is basically working except for this one thing. I did read that you could import the 'metabase' from IIS6 but I don't know if that is everything.
Since apparently everything else works, you would be better off at this time to require the users to use something other than a decimal point in the directory / user names.
Since apparently everything else works, you would be better off at this time to require the users to use something other than a decimal point in the directory / user names.
I recreated a new VM and redid the webserver from scratch. I then ported over the settings screen by screen. Net result is some improvement.
Works - http://192.168.1.104/test/test@att.com/ - Same as WS001
Works - https://192.168.1.104/test/test@att.com/ - Does not work on WS001
Bad - https://192.168.1.104/bb/0/test@att.com/ - Same as 001
Works - http://192.168.1.104/bbr/9/xxx-inc2754-x@x.com/ - Does not work on 001
The .com based accounts work on the local servers hard drive on both http and https. This improves over the production WS001 since these did not work on https.
On the production NAS box attached to the webserver where the files are stored it did not work on the https side of the webserver so that was consistent with the production webserver.
If I could get the https gets working all would be well. The https posts work just fine to the same directories. This is what I can't understand... why do posts work but gets don't for the .com based accounts.
Any thoughts?
Works - http://192.168.1.104/test/test@att.com/ - Same as WS001
Works - https://192.168.1.104/test/test@att.com/ - Does not work on WS001
Bad - https://192.168.1.104/bb/0/test@att.com/ - Same as 001
Works - http://192.168.1.104/bbr/9/xxx-inc2754-x@x.com/ - Does not work on 001
The .com based accounts work on the local servers hard drive on both http and https. This improves over the production WS001 since these did not work on https.
On the production NAS box attached to the webserver where the files are stored it did not work on the https side of the webserver so that was consistent with the production webserver.
If I could get the https gets working all would be well. The https posts work just fine to the same directories. This is what I can't understand... why do posts work but gets don't for the .com based accounts.
Any thoughts?
I don't have a setup like this one, but one thing which you haven't mentioned:
In IIS (and other servers) https goes to a single container. There's only 1 listener for the https requests. It has the 1 certificate you have for the server.
IIS does not care what the domain is with the request. If you have 2 domains
http://www.a.com
http://www.b.com
but your cert is for www.a.com, then even if the url is for b.com:
https://www.b.com
IIS will answer from the a.com listener, because that's what is listening on 443.
So, if your att.com urls work on b.com, but not on a.com, you'll get weird errors for a 443 (https) request even if you think you have said b.com .
In IIS (and other servers) https goes to a single container. There's only 1 listener for the https requests. It has the 1 certificate you have for the server.
IIS does not care what the domain is with the request. If you have 2 domains
http://www.a.com
http://www.b.com
but your cert is for www.a.com, then even if the url is for b.com:
https://www.b.com
IIS will answer from the a.com listener, because that's what is listening on 443.
So, if your att.com urls work on b.com, but not on a.com, you'll get weird errors for a 443 (https) request even if you think you have said b.com .
Only one server and it has port 80 and 443 open. This server has the only certificat for the domain.
What fails are https gets to any account that has ".com" in the account name. The accounts fail regardless of if they are stored on the drive in the server or on the NAS box. This has been working for 5 years but stopped working after Oct 29th as that is the last successful set of transactions.
All other accounts without ".com" in the account name remain fully fuctional.
I am clueless on the issue or how to resolve at this point.
What fails are https gets to any account that has ".com" in the account name. The accounts fail regardless of if they are stored on the drive in the server or on the NAS box. This has been working for 5 years but stopped working after Oct 29th as that is the last successful set of transactions.
All other accounts without ".com" in the account name remain fully fuctional.
I am clueless on the issue or how to resolve at this point.
I understand that you have 1 server. What I wondered was if you had 2 domain names identified in IIS. Perhaps you don't -- it was just a thought.
I googled your error message, and the following discussion sounds like a possible workaround:
http://social.technet.microsoft.com/Forums/en-US/configmgrsetup/thread/2cee3b82-9335-4a25-8f0f-747cca29c3da/
You change your configuration to allow the ccmisapi.dll ? The discussion is about IIS7, but sometimes Windows OS updates include changes which affect IIS in all its versions.
In any case, it sounds as if a rule changed for your IIS which is no longer allowing a url rewrite you have for the user login as part of the url.
I googled your error message, and the following discussion sounds like a possible workaround:
http://social.technet.microsoft.com/Forums/en-US/configmgrsetup/thread/2cee3b82-9335-4a25-8f0f-747cca29c3da/
You change your configuration to allow the ccmisapi.dll ? The discussion is about IIS7, but sometimes Windows OS updates include changes which affect IIS in all its versions.
In any case, it sounds as if a rule changed for your IIS which is no longer allowing a url rewrite you have for the user login as part of the url.
I tried to make this change but no luck. IIS6 doesn't have the config file so no way to edit it. I searched the server several times for something similar but no luck.
In looking at the inetsrv directory the last file updated was 6/28/2010 other than the MetaBase.xml which was updated today.
The error from my webserver log looks like this for an active account...
2013-01-08 05:06:40 W3SVC2018762905 WCIWS-001 192.168.2.101 GET /bb/0/20130101004135-inc59
Agree something changed after Oct 29 that is preventing Get only on accounts with ".com".
Other thoughts or recommendations?
In reading the link there is also a discusion about remove / reinstalling "DP". What is DP?
In looking at the inetsrv directory the last file updated was 6/28/2010 other than the MetaBase.xml which was updated today.
The error from my webserver log looks like this for an active account...
2013-01-08 05:06:40 W3SVC2018762905 WCIWS-001 192.168.2.101 GET /bb/0/20130101004135-inc59
Agree something changed after Oct 29 that is preventing Get only on accounts with ".com".
Other thoughts or recommendations?
In reading the link there is also a discusion about remove / reinstalling "DP". What is DP?
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
You're the only person with all of the IIS configuration rules in front of you, you're the one with the url rewrite rules, you're the person with the application code which reads the user email as the parameter from the url. You're also the person with the list of updates which have been made to your server over the past few months.
It sounds as if you were hoping that someone would be able to give you a quick answer. No one here has seen what you're seeing. There aren't a ton of IIS administrators on EE, so you might try an actual IIS or ASP.Net forum to see if someone there has run into this same update from Microsoft.