Users receive intermittent forbidden errors - Event ID 1314 - Sharepoint

Alvin,

I am using smartparts on the master page of the site. Due you think, this is
the reason I get Access Denied message whenever they are outdated. How did
you manage to resolve it? Any help would be appreciated. Thanks.

"Alvin" wrote:

> Hi Im not sure if we are having the same error but is there any solutions as off now? One of the reasons why i had this bug was because of the fact that im using smartparts that required asp.net to recompile them whenever it is outdated, iis is reset or when server restarts. Because of this i have to login as an administrator that has rights to compile the pages.
>
> Any idea?
>
> EggHeadCafe - .NET Developer Portal of Choice
> http://www.eggheadcafe.com
>

After I installed .NET 2.0 Framework SP1 and some other updates, I noticed
the error again. I saw some articles that prompted me to add a host header
value of the machine name to the SharePoint web application. I wanted the
user to try accessing the WFE directly after the 403 occurs to see if the
problem is the same that way. In any case, it was reported that the error
was fixed after that. It's been less than a day so I'm not sure if that
truely fixed the problem.

"stealthprism" wrote:

> I tried uninstalling the .NET hotfix KB928365, but the problem still exists.
> Has anyone found a solution? Please help !!!
>
>
> "Eric" wrote:
>
> > MSFT support said to uninstall KB928365. You'll find this in the Add/Remove
> > programs with "Show updates" checked off. It's one of the .NET Framework
> > updates.
> >
> > Make sure that you do the uninstall when people are off the system...you'll
> > also need to reboot after.
> >
> > So far so good, no HTTP 403 errors in two weeks.
> >
> >
> > "Kaj" wrote:
> >
> > > Hi,
> > >
> > > I too am having the same problem. I tried uninstalling the .NET hotfix
> > > 928365, but the problem still exists. Has anyone found a solution?
> > >
> > > Thanks in advance.
> > >
> > > Event Type: Information
> > > Event Source: ASP.NET 2.0.50727.0
> > > Event Category: Web Event
> > > Event ID: 1314
> > > Date: 11/5/2007
> > > Time: 11:03:43 AM
> > > User: N/A
> > > Computer: ***
> > > Description:
> > > Event code: 4011
> > > Event message: An unhandled access exception has occurred.
> > > Event time: 11/5/2007 11:03:43 AM
> > > Event time (UTC): 11/5/2007 4:03:43 PM
> > > Event ID: cc0effba819a40ecbcfbdbcb502eec4e
> > > Event sequence: 435
> > > Event occurrence: 1
> > > Event detail code: 0
> > >
> > > Application information:
> > > Application domain: /LM/W3SVC/730519273/Root-1-128387476431305372
> > > Trust level: bpm_WSS_Minimal
> > > Application Virtual Path: /
> > > Application Path: C:\Inetpub\wwwroot\wss\VirtualDirectories\80\
> > > Machine name: ***
> > >
> > > Process information:
> > > Process ID: 8996
> > > Process name: w3wp.exe
> > > Account name: CORP\***
> > >
> > > Request information:
> > > Request URL:
> > > http://***/EN/SALES/CONTRACTREVIEW/P...ovalForms.aspx
> > > Request path: /EN/SALES/CONTRACTREVIEW/Pages/CMSApprovalForms.aspx
> > > User host address: ***
> > > User: CORP\***
> > > Is authenticated: True
> > > Authentication Type: NTLM
> > > Thread account name: CORP\***
> > >
> > > Custom event details:
> > >
> > > For more information, see Help and Support Center at
> > > http://go.microsoft.com/fwlink/events.asp.
> > >
> > > "yarikcom" wrote:
> > >
> > > > Hi,
> > > > i'm having headache because of this problem. Is there anything I can do?
> > > > I need the solution greatly!!!
> > > > Thanks
> > > >
> > > > I have event 1314
> > > > source ASP.NET 2.0.50727.0
> > > >
> > > > Event code: 4011
> > > > Event message: An unhandled access exception has occurred.
> > > > Event time: 09.10.2007 13:56:46
> > > > Event time (UTC): 09.10.2007 10:56:46
> > > > Event ID: 8fdaab16e41c478ab7c48d7d8b1f36a2
> > > > Event sequence: 5587
> > > > Event occurrence: 1
> > > > Event detail code: 0
> > > >
> > > > Application information:
> > > > Application domain: /LM/W3SVC/1403363651/Root-1-128363579671871901
> > > > Trust level: WSS_Minimal
> > > > Application Virtual Path: /
> > > > Application Path: C:\Inetpub\wwwroot80\
> > > > Machine name: PORTAL
> > > >
> > > > Process information:
> > > > Process ID: 4104
> > > > Process name: w3wp.exe
> > > > Account name: ****\PortalServer
> > > >
> > > > Request information:
> > > > Request URL: http://portal/Расписание комнаты
> > > > переговоров/Lists/List/NewForm.aspx?RootFolder=/Расписание комнаты
> > > > переговоров/Lists/List&Source=http://portal/%25d0%25a0%25d0%25b0%25d1%2581%25d0%25bf%25d0%25b8%25d1%2581%25d0%25b0%25d0%25bd%25d0%25b8%25d0%25b5%2520%25d0%25ba%25d0%25be%25d0%25bc%25d0%25bd%25d0%25b0%25d1%2582%25d1%258b%2520%25d0%25bf%25d0%25b5%25d1%2580%25d0%25b5%25d0%25b3%25d0%25be%25d0%25b2%25d0%25be%25d1%2580%25d0%25be%25d0%25b2/Pages/default.aspx
> > > > Request path: /Расписание комнаты переговоров/Lists/List/NewForm.aspx
> > > > User host address: 192.168.15.26
> > > > User: BMS-CONSULTING\YaroslavB
> > > > Is authenticated: True
> > > > Authentication Type: NTLM
> > > > Thread account name: *****\PortalServer
> > > >
> > > > Custom event details:
> > > >
> > > > Дополнительные сведения можно найти в центре справки и поддержки, в
> > > > "http://go.microsoft.com/fwlink/events.asp".

Has anyone found a "real" fix for this? I have removed KB928365 but am still
getting the intermittent 1314.

After installing .NET 2.0 SP1 and WSS3/MOSS SP1, I saw the return of the
403's on our MySites, a separate WebApplication.

I managed to squash the 403's by increasing the trust in the Web.Config of
the webpplication to "WSS_Medium". The 403's were gone for a week, but now I
am getting reports again of new 403's...

This is frustating. I have this problem under investigation with Microsoft
Support, but no solution yet.

Victor Vogelpoel
Macaw Nederland B.V.

If this is in a Publishing or Content Deployment scenario (e.g.
Authoring/Staging --> Production), ensure that all the artefacts (Master
Pages, Images, etc.) are all checked-in, published and approved.

I was receiving this error in addition to 401.5 in the IIS error log for a
site with anonymous authentication and nothing worked until I rolled-back to
a blank site.

Further ****ysis revealed that the Master Page etc. weren't
checked-in/published and after remedying this and running a full content
deployment, everything worked and the error went away.

"VictorV" wrote:

>
> After installing .NET 2.0 SP1 and WSS3/MOSS SP1, I saw the return of the
> 403's on our MySites, a separate WebApplication.
>
> I managed to squash the 403's by increasing the trust in the Web.Config of
> the webpplication to "WSS_Medium". The 403's were gone for a week, but now I
> am getting reports again of new 403's...
>
> This is frustating. I have this problem under investigation with Microsoft
> Support, but no solution yet.
>
> Victor Vogelpoel
> Macaw Nederland B.V.

I found a solution to the 403 Forbidden (event id 1314) errors. Microsoft
Support couldn't fix it but my two minute session with SysInternal's FileMon
revealed the cause:
--> w3wp.exe attempts to access the bin/ directory of the
webapplication in context of the requesting (non-admin) user and fails with
an access denied.

SYMPTOMS
-User (non admin) wants to create a new list item (eg calenderitem, ...) or
upload a file and sees a 403 Forbidden. The 'new' page is not show.
- User (non admin) wants to edit a list item (eg blogpost) and sees a 403
Forbidden. The 'edit' page is not shown.
- A Farm Administrator has NO issues with these 'new'/'edit' pages and is
able to edit and save content.

CAUSE
w3wp.exe (IIS worker process for ASP.NET) tries to look into the /bin
directory in the context of the requesting user account (impersonation), but
fails for non-admin users. The bin/ directory is not readable for normal
users but is readable for administrators.
I believe this is an ASP.NET 2.0 bug that is related to KB 928365. This
hotfix is removed when you install .NET 2.0 Service Pack 1. SP1 contains the
solution from KB 928365 and thus the problems continue.
I don't think WSS3/MOSS or WSS3/MOSS Service Pack 1 causes this issue.

WORKAROUND/SOLUTION
Make sure your normal user accounts can access the /bin directory in the
webapplication:
- Open an Windows Explorer for the /bin directory of your webapplication and
display its properties.
- On the security tab, add the local server group "SERVER\Users" to the
list, ("SERVER\Users" usually contains "DOMAIN\Users") and select the
following rights for "SERVER\Users": "Read & Execute", "List Folder
Contents", "Read". Click OK to apply the new settings.

The 403's should be gone.
Do this for every webapplication in your farm.

Haapy sharepointing,

Victor Vogelpoel
Macaw Nederland B.V.


"Rob M" wrote:

> This one has me stumped since we were running great for months.
>
> Intermittently users are being denied access to various areas of our
> MOSS/SharePoint 2007 site. This was a clean install and is a very basic
> setup. MOSS is running on Win2k3 R2 x64 machine with all updates applied. The
> only other machine in the farm is an SQL2005 Win2k3 R2 x64 server with all
> updates applied.
>
> This happens randomly when a user tries to create new calendar item, upload
> a file, add to or create a new list, and if they have access, manage various
> permissions. It started about 3 weeks ago and now is happening constantly. In
> the past I was able to fix this for a couple days by performing an IISRESET,
> but now that is no longer working.
> Here's the strange part. Now I can temporarily fix this error if I Remote
> into the MOSS server and open the affected list/library/calendar area using
> our domain admin account. It opens fine without the permissions error and I
> then tell the user to try again. The user then has no problems for a few
> hours.
>
> I've seen a few others reporting this in various forums and newsgroups, but
> no one has posted a resolution. The only thing I have to work off is this
> description and the error that appears in the MOSS server's event viewer.
> (See Event at bottom) I have called MSFT support and opened a case, but they
> are back logged on SharePoint issues and will be calling me back in a few
> days. If I get this resolved I will follow up here at later date, but any
> immediate help would be appreciated.
>
> Thanks!
> Rob Morris
>
> -----------Event ID 1314 ------------
>
> Event Type: Information
> Event Source: ASP.NET 2.0.50727.0
> Event Category: Web Event
> Event ID: 1314
> Date: 7/25/2007
> Time: 8:16:40 AM
> User: N/A
> Computer: INTRANET
> Description:
> Event code: 4011
> Event message: An unhandled access exception has occurred.
> Event time: 7/25/2007 8:16:40 AM
> Event time (UTC): 7/25/2007 12:16:40 PM
> Event ID: b9753e79dae343eeb23914475ca46f52
> Event sequence: 57
> Event occurrence: 2
> Event detail code: 0
>
> Application information:
> Application domain: /LM/W3SVC/1739125262/Root-1-128298391918795347
> Trust level: WSS_Minimal
> Application Virtual Path: /
> Application Path: D:\WEBSITES\EandO.EDITEDDOMAIN.COM\
> Machine name: INTRANET
>
> Process information:
> Process ID: 4432
> Process name: w3wp.exe
> Account name: EDITEDDOMAIN\mossuser
>
> Request information:
> Request URL:
> http://eando.EDITEDDOMAIN.com/GIS/Li...ndarPeriod=Day
> Request path: /GIS/Lists/Calendar/NewForm.aspx
> User host address: 10.215.14.13
> User: EDITEDDOMAIN\EDITEDUSER
> Is authenticated: True
> Authentication Type: NTLM
> Thread account name: EDITEDDOMAIN\mossuser
>

Peter,
thanks for your reply, but it is not a Publishing/Content deployment scenario.
I did find the cause though. Read it at the root of this thread: I replied
at Rob M's initial post.

Victor Vogelpoel
Macaw Nederland B.V.


"PeterB" wrote:

> If this is in a Publishing or Content Deployment scenario (e.g.
> Authoring/Staging --> Production), ensure that all the artefacts (Master
> Pages, Images, etc.) are all checked-in, published and approved.
>
> I was receiving this error in addition to 401.5 in the IIS error log for a
> site with anonymous authentication and nothing worked until I rolled-back to
> a blank site.
>
> Further ****ysis revealed that the Master Page etc. weren't
> checked-in/published and after remedying this and running a full content
> deployment, everything worked and the error went away.
>
> "VictorV" wrote:
>
> >
> > After installing .NET 2.0 SP1 and WSS3/MOSS SP1, I saw the return of the
> > 403's on our MySites, a separate WebApplication.
> >
> > I managed to squash the 403's by increasing the trust in the Web.Config of
> > the webpplication to "WSS_Medium". The 403's were gone for a week, but now I
> > am getting reports again of new 403's...
> >
> > This is frustating. I have this problem under investigation with Microsoft
> > Support, but no solution yet.
> >
> > Victor Vogelpoel
> > Macaw Nederland B.V.

Hello,

The users of my organisation had also those 403 errors when they tried to
upload a file to Windows Share Point Services 3.0.
I spent many hours on the internet to find a solution for this problem.
Several times I found that removing hot fix 928365 should fix the problem.
Only I could not find that update at Add and Remove Software.
I supposed that it was replaced by the .NET 2.0 Service Pack 1 but didn’t
know for sure, because it wasn’t listed at the detail page for that update.
Today I found the post from Victor with the working around.
After adjusting the rights for the group Users those 403 where gone.

Thanks Victor! ;-)

Martijn ten Kate
Beenen B.V.


"VictorV" wrote:

> I found a solution to the 403 Forbidden (event id 1314) errors. Microsoft
> Support couldn't fix it but my two minute session with SysInternal's FileMon
> revealed the cause:
> --> w3wp.exe attempts to access the bin/ directory of the
> webapplication in context of the requesting (non-admin) user and fails with
> an access denied.
>
> SYMPTOMS
> -User (non admin) wants to create a new list item (eg calenderitem, ...) or
> upload a file and sees a 403 Forbidden. The 'new' page is not show.
> - User (non admin) wants to edit a list item (eg blogpost) and sees a 403
> Forbidden. The 'edit' page is not shown.
> - A Farm Administrator has NO issues with these 'new'/'edit' pages and is
> able to edit and save content.
>
> CAUSE
> w3wp.exe (IIS worker process for ASP.NET) tries to look into the /bin
> directory in the context of the requesting user account (impersonation), but
> fails for non-admin users. The bin/ directory is not readable for normal
> users but is readable for administrators.
> I believe this is an ASP.NET 2.0 bug that is related to KB 928365. This
> hotfix is removed when you install .NET 2.0 Service Pack 1. SP1 contains the
> solution from KB 928365 and thus the problems continue.
> I don't think WSS3/MOSS or WSS3/MOSS Service Pack 1 causes this issue.
>
> WORKAROUND/SOLUTION
> Make sure your normal user accounts can access the /bin directory in the
> webapplication:
> - Open an Windows Explorer for the /bin directory of your webapplication and
> display its properties.
> - On the security tab, add the local server group "SERVER\Users" to the
> list, ("SERVER\Users" usually contains "DOMAIN\Users") and select the
> following rights for "SERVER\Users": "Read & Execute", "List Folder
> Contents", "Read". Click OK to apply the new settings.
>
> The 403's should be gone.
> Do this for every webapplication in your farm.
>
> Haapy sharepointing,
>
> Victor Vogelpoel
> Macaw Nederland B.V.
>
>
> "Rob M" wrote:
>
> > This one has me stumped since we were running great for months.
> >
> > Intermittently users are being denied access to various areas of our
> > MOSS/SharePoint 2007 site. This was a clean install and is a very basic
> > setup. MOSS is running on Win2k3 R2 x64 machine with all updates applied. The
> > only other machine in the farm is an SQL2005 Win2k3 R2 x64 server with all
> > updates applied.
> >
> > This happens randomly when a user tries to create new calendar item, upload
> > a file, add to or create a new list, and if they have access, manage various
> > permissions. It started about 3 weeks ago and now is happening constantly. In
> > the past I was able to fix this for a couple days by performing an IISRESET,
> > but now that is no longer working.
> > Here's the strange part. Now I can temporarily fix this error if I Remote
> > into the MOSS server and open the affected list/library/calendar area using
> > our domain admin account. It opens fine without the permissions error and I
> > then tell the user to try again. The user then has no problems for a few
> > hours.
> >
> > I've seen a few others reporting this in various forums and newsgroups, but
> > no one has posted a resolution. The only thing I have to work off is this
> > description and the error that appears in the MOSS server's event viewer.
> > (See Event at bottom) I have called MSFT support and opened a case, but they
> > are back logged on SharePoint issues and will be calling me back in a few
> > days. If I get this resolved I will follow up here at later date, but any
> > immediate help would be appreciated.
> >
> > Thanks!
> > Rob Morris
> >
> > -----------Event ID 1314 ------------
> >
> > Event Type: Information
> > Event Source: ASP.NET 2.0.50727.0
> > Event Category: Web Event
> > Event ID: 1314
> > Date: 7/25/2007
> > Time: 8:16:40 AM
> > User: N/A
> > Computer: INTRANET
> > Description:
> > Event code: 4011
> > Event message: An unhandled access exception has occurred.
> > Event time: 7/25/2007 8:16:40 AM
> > Event time (UTC): 7/25/2007 12:16:40 PM
> > Event ID: b9753e79dae343eeb23914475ca46f52
> > Event sequence: 57
> > Event occurrence: 2
> > Event detail code: 0
> >
> > Application information:
> > Application domain: /LM/W3SVC/1739125262/Root-1-128298391918795347
> > Trust level: WSS_Minimal
> > Application Virtual Path: /
> > Application Path: D:\WEBSITES\EandO.EDITEDDOMAIN.COM\
> > Machine name: INTRANET
> >
> > Process information:
> > Process ID: 4432
> > Process name: w3wp.exe
> > Account name: EDITEDDOMAIN\mossuser
> >
> > Request information:
> > Request URL:
> > http://eando.EDITEDDOMAIN.com/GIS/Li...ndarPeriod=Day
> > Request path: /GIS/Lists/Calendar/NewForm.aspx
> > User host address: 10.215.14.13
> > User: EDITEDDOMAIN\EDITEDUSER
> > Is authenticated: True
> > Authentication Type: NTLM
> > Thread account name: EDITEDDOMAIN\mossuser
> >

I found the solution after spending a week on this:
http://allsharepoint.blogspot.com/20...-http-403.html

-Parshva
"Chris S" wrote:

> James,
> I am also having the same issue as the other gentleman. I tried to run the
> Hotfix you suggested, but no luck. The issue he described above is just like
> what I am experiencing. On the server that is having the issue I have MOSS,
> CRM, and Project Server.
>
> Here is a copy of the error in the event viewer:
>
> Event Type: Information
> Event Source: ASP.NET 2.0.50727.0
> Event Category: Web Event
> Event ID: 1314
> Date: 8/10/2007
> Time: 9:03:22 AM
> User: N/A
> Computer: PORTAL
> Description:
> Event code: 4011
> Event message: An unhandled access exception has occurred.
> Event time: 8/10/2007 9:03:22 AM
> Event time (UTC): 8/10/2007 1:03:22 PM
> Event ID: a2914b985825406bb79beddbfa15089b
> Event sequence: 1143
> Event occurrence: 6
> Event detail code: 0
>
> Application information:
> Application domain: /LM/W3SVC/1/ROOT-1-128312004784687500
> Trust level: WSS_Minimal
> Application Virtual Path: /
> Application Path: c:\inetpub\wwwroot\
> Machine name: PORTAL
> Process information:
> Process ID: 1612
> Process name: w3wp.exe
> Account name: NT AUTHORITY\NETWORK SERVICE
>
> Request information:
> Request URL: http://portal/Lists/Employee
> Calendar/NewForm.aspx?Source=http://portal/default.aspx
> Request path: /Lists/Employee Calendar/NewForm.aspx
> User host address: 10.1.1.164
> User: CONNEAUTTELEPHO\agildone
> Is authenticated: True
> Authentication Type: Negotiate
> Thread account name: NT AUTHORITY\NETWORK SERVICE
> Custom event details:
>
>
> Any ideas or help on this issue would be appreciated.
>
> Thanks,
> Chris
>
> "mr-magoo" wrote:
>
> > James, this solved my difficult-to-track-down problem as well. Thank you for
> > this posing !!!
> >
> > "James Morey [MSFT]" wrote:
> >
> > > Hi Rob,
> > >
> > > The most likely cause is a bug in .NET 2.0. There is a hotfix available.
> > > Look at KB 923028(http://support.microsoft.com/?id=923028). The association
> > > with the other 3 events is a good indicator of this problem.
> > >
> > > Hope this helps you.
> > >
> > > --
> > > James R. Morey [MS]
> > > This posting is provided "AS IS" with no warranties, and confers no rights.
> > > Use of included script samples are subject to the terms specified at
> > > http://www.microsoft.com/info/cpyright.htm
> > >
> > > Office SharePoint Server 2007
> > > (http://technet2.microsoft.com/Office...1361c1033.mspx)
> > >
> > > Windows SharePoint Services 3.0
> > > (http://technet2.microsoft.com/window...a20531033.mspx
> > > )
> > >
> > > ========================
> > > "Rob M" <RobM@discussions.microsoft.com> wrote in message
> > > news:1EF75468-D083-4194-8F66-0E92C093EF6B@microsoft.com...
> > > > Hi James thanks for the reply.
> > > >
> > > > I went through my events and I was receiving the 7076, 6482, and 6398
> > > > Event
> > > > IDs in the past months but they stopped at about the same time the 1314
> > > > started. They only overlapped for 3 days. Now I am just receiving Event ID
> > > > 1314 but no other noticeable errors.
> > > >
> > > > Thanks again for the reply.
> > > >
> > > > Rob
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "James Morey [MSFT]" wrote:
> > > >
> > > >> Hi Rob,
> > > >>
> > > >> Are you also seeing Event IDs 7076, 6482, or 6398 in App Log
> > > >> (Source="Office
> > > >> SharePoint Server") at about the same time as the event you have below?
> > > >>
> > > >> --
> > > >> James R. Morey [MS]
> > > >> This posting is provided "AS IS" with no warranties, and confers no
> > > >> rights.
> > > >> Use of included script samples are subject to the terms specified at
> > > >> http://www.microsoft.com/info/cpyright.htm
> > > >>
> > > >> Office SharePoint Server 2007
> > > >> (http://technet2.microsoft.com/Office...1361c1033.mspx)
> > > >>
> > > >> Windows SharePoint Services 3.0
> > > >> (http://technet2.microsoft.com/window...a20531033.mspx
> > > >> )
> > > >>
> > > >> ========================
> > > >> "Rob M" <RobM@discussions.microsoft.com> wrote in message
> > > >> news:869B8EB9-924A-49F4-9017-345BA55D7524@microsoft.com...
> > > >> > This one has me stumped since we were running great for months.
> > > >> >
> > > >> > Intermittently users are being denied access to various areas of our
> > > >> > MOSS/SharePoint 2007 site. This was a clean install and is a very basic
> > > >> > setup. MOSS is running on Win2k3 R2 x64 machine with all updates
> > > >> > applied.
> > > >> > The
> > > >> > only other machine in the farm is an SQL2005 Win2k3 R2 x64 server with
> > > >> > all
> > > >> > updates applied.
> > > >> >
> > > >> > This happens randomly when a user tries to create new calendar item,
> > > >> > upload
> > > >> > a file, add to or create a new list, and if they have access, manage
> > > >> > various
> > > >> > permissions. It started about 3 weeks ago and now is happening
> > > >> > constantly.
> > > >> > In
> > > >> > the past I was able to fix this for a couple days by performing an
> > > >> > IISRESET,
> > > >> > but now that is no longer working.
> > > >> > Here's the strange part. Now I can temporarily fix this error if I
> > > >> > Remote
> > > >> > into the MOSS server and open the affected list/library/calendar area
> > > >> > using
> > > >> > our domain admin account. It opens fine without the permissions error
> > > >> > and
> > > >> > I
> > > >> > then tell the user to try again. The user then has no problems for a
> > > >> > few
> > > >> > hours.
> > > >> >
> > > >> > I've seen a few others reporting this in various forums and newsgroups,
> > > >> > but
> > > >> > no one has posted a resolution. The only thing I have to work off is
> > > >> > this
> > > >> > description and the error that appears in the MOSS server's event
> > > >> > viewer.
> > > >> > (See Event at bottom) I have called MSFT support and opened a case, but
> > > >> > they
> > > >> > are back logged on SharePoint issues and will be calling me back in a
> > > >> > few
> > > >> > days. If I get this resolved I will follow up here at later date, but
> > > >> > any
> > > >> > immediate help would be appreciated.
> > > >> >
> > > >> > Thanks!
> > > >> > Rob Morris
> > > >> >
> > > >> > -----------Event ID 1314 ------------
> > > >> >
> > > >> > Event Type: Information
> > > >> > Event Source: ASP.NET 2.0.50727.0
> > > >> > Event Category: Web Event
> > > >> > Event ID: 1314
> > > >> > Date: 7/25/2007
> > > >> > Time: 8:16:40 AM
> > > >> > User: N/A
> > > >> > Computer: INTRANET
> > > >> > Description:
> > > >> > Event code: 4011
> > > >> > Event message: An unhandled access exception has occurred.
> > > >> > Event time: 7/25/2007 8:16:40 AM
> > > >> > Event time (UTC): 7/25/2007 12:16:40 PM
> > > >> > Event ID: b9753e79dae343eeb23914475ca46f52
> > > >> > Event sequence: 57
> > > >> > Event occurrence: 2
> > > >> > Event detail code: 0
> > > >> >
> > > >> > Application information:
> > > >> > Application domain: /LM/W3SVC/1739125262/Root-1-128298391918795347
> > > >> > Trust level: WSS_Minimal
> > > >> > Application Virtual Path: /
> > > >> > Application Path: D:\WEBSITES\EandO.EDITEDDOMAIN.COM\
> > > >> > Machine name: INTRANET
> > > >> >
> > > >> > Process information:
> > > >> > Process ID: 4432
> > > >> > Process name: w3wp.exe
> > > >> > Account name: EDITEDDOMAIN\mossuser
> > > >> >
> > > >> > Request information:
> > > >> > Request URL:
> > > >> > http://eando.EDITEDDOMAIN.com/GIS/Li...ndarPeriod=Day
> > > >> > Request path: /GIS/Lists/Calendar/NewForm.aspx
> > > >> > User host address: 10.215.14.13
> > > >> > User: EDITEDDOMAIN\EDITEDUSER
> > > >> > Is authenticated: True
> > > >> > Authentication Type: NTLM
> > > >> > Thread account name: EDITEDDOMAIN\mossuser
> > > >> >
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >