please check in the IIS log for the 400 response to see which request caused
this problem.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Andrew Connell" <sp...@aNOSPAMMEconnell.com> wrote in message
news:#PbYwz1v...@TK2MSFTNGP12.phx.gbl...
03:51:32 127.0.0.1 - - 400
So I can't tell what it is. We did modify the permissions within IIS, but
only in the virtual directory for our web project (not the CMS directories I
see in the IIS log such as /NR/) and we also made an authentication change
in the web.config file. Granted, I did all of this with the MCS consultant
that was onsite helping us and everything seemed to work ok. My permissions
on the CMS directories:
/[project vdir]/ : anon access checked, integrated windows auth checked
/[project vdir]/cms/ : same as above
/NR/: same as above
/NRConfig/ : basic auth (default domain & realm blank), integrated windows
auth checked (no anon access changed)
Here's what we added within our web.config:
> authentication node: mode=windows; identity impersonate="true"
> authorization node: <deny users="?" />
Some of this was done (I think) so a certain part of the code would be able
to use the current logged in user's credentials to query our AD.
Some of this may mena absolutely nothing to the error, just thought I'd
mention it if you have me looking in the IIS log. I thought the error would
be in the database after our database restore fixed the problems last time
for about 36hrs.
-AC
"Stefan [MSFT]" <ste...@online.microsoft.com> wrote in message
news:eDpzJf3v...@TK2MSFTNGP10.phx.gbl...
the entry looks strange as it only contains 5 columns.
It seems you modified the Logfile settings.
Please ensure that URI Stem and URI Query, User Name, Client IP, Method,
User Agent, Referer are activated.
Cheers,
Stefan.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"AC" <sp...@aNOSPAM.com> wrote in message
news:OKnhov5v...@TK2MSFTNGP12.phx.gbl...
From the IIS log, and from the timing of my errors, is it realy the 400
error that's terribly important because I have the XML Parser error (request
too big) before I get the 400 (again, I only get the 400 error when I try to
expand a channel or view it's properties/postings... I get the parser error
after the login process when t he status bar says "Expanding Tree"). My
site isn't that big yet... we're still in the process of biulding templates
and custom placeholder controls. We prob have roughly 50-75 postings at
this time... with only 20-40% filled with lots of content (the others are
dummy default pages that we setup for the content owners so they wouldn't
see the default CMS page for empty channels).
#Software: Microsoft Internet Information Services 5.1
#Version: 1.0
#Date: 2003-12-11 11:04:26
#Fields: date time c-ip cs-username cs-method cs-uri-stem cs-uri-query
sc-status cs(User-Agent) cs(Referer)
[[[ START LOGIN PROCESS... AT THIS POINT I OPENED SITE MANAGER ]]]
2003-12-11 11:04:26 127.0.0.1 - GET /NR/System/ClientUI/login.asp - 200
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) -
2003-12-11 11:04:26 127.0.0.1 - GET
/NR/System/ClientUI/Titlebar/Resolution.ico - 304
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) -
2003-12-11 11:04:42 127.0.0.1 - POST /NR/System/Marshalling/resstub.asp -
200 - -
2003-12-11 11:07:40 127.0.0.1 - POST /NR/System/Marshalling/resstub.asp -
200 - -
2003-12-11 11:07:41 127.0.0.1 - GET /NR/System/ClientUI/aecm.asp - 200
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) -
2003-12-11 11:07:41 127.0.0.1 - GET
/NR/System/ClientUI/Titlebar/Resolution.ico - 304
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) -
2003-12-11 11:07:41 127.0.0.1 - GET /NR/System/ClientUI/Toolbar/Cut.gif -
304 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) -
2003-12-11 11:07:41 127.0.0.1 - GET /NR/System/ClientUI/Toolbar/Copy.gif -
304 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) -
2003-12-11 11:07:41 127.0.0.1 - GET /NR/System/ClientUI/Toolbar/Paste.gif -
304 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) -
2003-12-11 11:07:41 127.0.0.1 - GET /NR/System/ClientUI/Toolbar/Delete.gif -
304 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) -
2003-12-11 11:07:41 127.0.0.1 - GET
/NR/System/ClientUI/Toolbar/Refresh.gif - 304
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) -
2003-12-11 11:07:41 127.0.0.1 - GET
/NR/System/ClientUI/Toolbar/Properties.gif - 304
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322) -
2003-12-11 11:07:45 127.0.0.1 - POST /NR/System/Marshalling/resstub.asp -
200 - -
2003-12-11 11:07:48 127.0.0.1 - POST /NR/System/Marshalling/resstub.asp -
200 - -
2003-12-11 11:07:48 127.0.0.1 - POST /NR/System/Marshalling/resstub.asp -
200 - -
[[[ AT THIS POINT I GOT THE FIRST ERROR ABOUT THE XML PARSER AND A REQUEST
THAT WAS TOO BIG... AFTER CLICKING OK, NO MORE ENTRIES IN IIS LOG AND SITE
MANAGER LOADS]]]
[[[ NOW I CLICK ON A CHANNEL IN SITE MANAGER ]]]
2003-12-11 11:08:04 127.0.0.1 - - - - 400 - -
[[[ THE 400 IS THE ERROR I GET WHEN CLICKING ON A CHANNEL IN SITE
MANAGER ]]]
"Stefan [MSFT]" <ste...@online.microsoft.com> wrote in message
news:uBtOJQ9v...@TK2MSFTNGP09.phx.gbl...
please install SiteManager on a different box and redo the test.
If the problem reoccurs, please check if the IP address in front of the 400
is still 127.0.0.1 or the IP of SiteManager.
We need to check if the request was sent by site manager or if this is one
of the http postbacks done by the server itself.
Cheers,
Stefan.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Andrew Connell" <sp...@aNOSPAMMEconnell.com> wrote in message
news:e0yeIg9v...@tk2msftngp13.phx.gbl...
We've already had one developer reinstall CMS & SP1 to fix this issue with
no luck. I had her send me her I'll do it on my workstation today. Should
I uninstall everything (CMS) first?
-AC
"Stefan [MSFT]" <ste...@online.microsoft.com> wrote in message
news:essu7n9...@tk2msftngp13.phx.gbl...
I checked my build server this morning when I got in and noticed that it
doesn't have any 400 status reports within the IIS log. The build server
has the XML parser error when I login to Site Manager, however it doesn't
have the 400 status. It's web.config doesn't have an <identity> node under
<authentication> node and it also is allowing all users in the
<authorization> node. I tried changing these but it didn't make a
difference.
-AC
"Stefan [MSFT]" <ste...@online.microsoft.com> wrote in message
news:essu7n9...@tk2msftngp13.phx.gbl...
Sorry for so many followup posts...
One thing I have also tried is setting up a database from a backup last week
(prior to the errors we were receiving) on my local workstation and Site
Manager ran just fine. So that implied it was something in the database
that was causing the error since the CMS runtime engine was the same one
being used that was throwing the errors... it was just pointing to a
different database.
-AC
"Stefan [MSFT]" <ste...@online.microsoft.com> wrote in message
news:essu7n9...@tk2msftngp13.phx.gbl...
A install of CMS & SP1 on clean box, as well as reinstalling CMS and SP1
haven't helped. On both boxes, the first time I logged in, I got the XML
parser error again, but I didn't get the 400 error. Then I closed Site
Manager and reopened it... this time I got the XML parser and then the 400
error. Same things in the IIS log... same IP.
Any other ideas?
-AC
"Stefan [MSFT]" <ste...@online.microsoft.com> wrote in message
news:essu7n9...@tk2msftngp13.phx.gbl...
if it is based on the database, then this is most likely a database
corruption.
You should go with the backup.
If this is not an option, please open a support case with Microsoft to let
us analyze the database corruption to see if it can be fixed.
Cheers,
Stefan.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"AC" <sp...@aNOSPAMMEconnell.com> wrote in message
news:e8YAc7#vDHA...@TK2MSFTNGP11.phx.gbl...
"Andrew Connell" <sp...@aNOSPAMMEconnell.com> wrote in message news:%23PbYwz1...@TK2MSFTNGP12.phx.gbl...
that are good news!
Sounds like you are talking about the "Request to big" limit?
Cheers,
Stefan.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"AC" <sp...@aNOSPAMMEconnell.com> wrote in message
news:emv8VUBw...@tk2msftngp13.phx.gbl...
Cheers,
Stefan.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Stefan [MSFT]" <ste...@online.microsoft.com> wrote in message
news:#PYcwiJw...@TK2MSFTNGP11.phx.gbl...
Yes, that was the root of the problem, but I found it very interesting that
Site Manager loaded everything in the Deleted Items folder (err... channel)
as well. I resolved this with help from Microsoft Support... and in talking
with them, they seemed a little surprised as well (aparently it wasn't
documented anywhere regarding the deleted items). The root of the problem:
we were doing a bulk import of content from an old site. We'd pull in
hundreds of press releases at a time... make sure they were ok, and then
realized we needed a new placeholder or something. So we'd delete the old
releases and reimport them. This accumulation overflowed the Deleted Items.
-AC
"Stefan [MSFT]" <ste...@online.microsoft.com> wrote in message
news:%23PYcwiJ...@TK2MSFTNGP11.phx.gbl...
Yup... that's what we did to fix it... we added a zero so we could just get
into Site Manager. Apparently the XML error was causing Site Manager to be
a unstable and thus causing the HTTP 400 error as well. Lesson learned.
-AC
"Stefan [MSFT]" <ste...@online.microsoft.com> wrote in message
news:e%23c7nnJw...@TK2MSFTNGP10.phx.gbl...
that's true. I knew about items in the root but not items in the deleted
items folder...
Cheers,
Stefan.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"AC" <sp...@aNOSPAMMEconnell.com> wrote in message
news:uO#rDOLwD...@TK2MSFTNGP09.phx.gbl...