Check that the patch hasn't been reinstalled during an update ? You never know

We are still having the 403 Forbidden errors with our intranet MOSS
server. Your upload  issue is a 403 as well.
It seems something goes terribly wrong when MOSS needs to impersonate
the user and .NET 2.0 is failing somehow.

We are running .NET 2.0/3.0 SP1 and WSS/MOSS SP1 and seeing 403
Forbiddens with MySites (not our portal): 'normal' users  cannot create
or edit blogposts on their mysites, administrators have no problems.
The kb928365 patch is part of .NET 2.0 SP1 and thus is causing these
403 Forbidden problems with MOSS. Microsoft even aknowledges this in a
KB article!

I've had Microsoft Support look at this issue, but no solution. I've
upgraded trust for the MySite web application to Full trust, but no
avail.
The problem  seems to appear at random times: users can blog several
days at a time and then 403's appear again. No idea yet what sparks
this. A busy server?

Update over my previous post: Problem solved?

Today I used SysInternals FileMon to monitor file access when I try
to create a blog post on my MySite.
Like expected, no webpage to create a post, but the 403 Forbidden
response.
I investigated the FileMon trace and found out that w3wp.exe (IIS
Worker process) was trying to access the /bin directory of the
webapplication of the MySites and receives an ACCESS DENIED.
There's nothing in the /bin directory, but this access denied seems
to be causing the 403 Forbidden.

To try to remedy, I openened the properties of /bin directory in
Windows Explorer and added the servers local "Users" group with "Read
& Execute", List Folder Contents" & Read" permission to the user list
on the Security Tab.
Instantly, the create post webpage seemed to work  again!

The local "Users" group already includes the "MACAW\Domain Users"
group, as this server is part of our MACAW domain. My own domain
account (no administrative permissions) now has access to read
the /bin/ directory. My administrative account already had access to
the /bin/ directory because of default settings on the directory
(assigned when SharePoint Central Admin created the WebApplication).

I will still be monitoring the MySites for 403's. Hopefully this
discovery and change will get rid of the 403's forgood this time...

I'm not following what you are doing that causes the 403 error. Are you
simply trying to create a blog post on your My Site? If so, this works
in our environment out of the box, so there must be something awry in
your setup.

Of course it may well be something awry in my setup, but I had no
clues where to look for up to an hour ago.

Creating a blogpost, uploading a document, creating a wiki library,
all fail with a 403 forbidden for a 'normal' user (non admin).

The 403 problem  is connected with hotfix kb928365, which is now part
of .NET 2.0 SP1. We have both .NET 2.0/3.0 SP1 and WSS3/MOSS SP1
installed (along with the latest server hotfixes).
I'll be rolling out this week's WSS3/MOSS post-SP1 hotfixes at the
end of the week.

There are people who are reporting the same issue  in various forums
and blogs, but no solution at hand. I even had Microsoft Support look
into it, but to no avail. They're swamped with SharePoint issues.

On my setup: my Webapplications are NOT created on the C: drive in
the wwwroot location, but on another drive. Kerberos is configured
and HTTPS is used for every webapplication (certificates are from our
own Certificate Authority Services.)
I have two different farms, only the MySites of my intranet farm has
these 403 forbidden issues, but not consistent.

To recreate the issue  that you are seeing I would install WSS
v3, apply WSS v3 SP1, and subsequently apply .NET 3.0 SP1 (you cannot
run WSS v3 on .NET 2.0). Then attempting to upload  a document, etc. as a
non-admin to a My Site results in a 403 response. Is that correct?

I'm assuming Win2k3 SP2, SQL Server 2005 SP2, single  box running all
roles. Does that sum it up?

I'm a developer, so I'm aggressive in updating my development
environment but I guess I make a cautious admin because I'm slow to
alter our production environment. Sounds like you are very aggressive in
installing hot fixes to your environments. I typically only apply a hot
fix if my users  are complaining about the specific problem  the hot fix
addresses. Otherwise, I wait until it is included in a service pack and
even then, if I can, I wait to hear how well it goes in my test
environment and also how well it goes for other early adopters.

Recreating the issue  would be something like that indeed. You don't
mention installing MOSS (MySites)
My installation path was (hardware: x64)
- Windows 2003 x64 > Windows 2003 SP2 > MOSS (and .NET 3.0) > .NET
2.0/3.0 SP1 > WSS3 SP1 > MOSS SP1.
- server has frontend, search, and query role
- SQL cluster server is used as db backend (so not a single  server
farm)
- All webapplications are installed on a different location than
c:\wwwroot. (Default webapplication disabled)
- All sites accessed through HTTPS; certificates from internal CA.
Dedicated intranet IP addresses.
- All sites use kerberos (which was quite a 'challenge', but I got it
nailed), IE uses local intranet zone through group policy.

I have two MOSS farms (intranet and extranet) in which only the
MySites of the intranet cause these 403 Forbidden problems.
I've had the 403 problems on the extranet farm before (all sites when
pre-.NET 2.0 SP1), and 'fixed' them by uninstalling kb928365.
As of installing .NET 2.0/3.0 SP1 and later WSS3/MOSS SP1, the
MySites on the intranet farm started to show the 403's again. No
issues anymore on the extranet farm. Curious, not?

I am a developer as well
(www.dotnetjunkies.com/.../133629
.aspx), and I am cautious with installing hotfixes on production
systems as well. The 403's are seriousely cripling functionality on
my intranet: Macaw is blogging extensively internally and non-working
blogs (and uploads and creating libraries and...) on the mysites has
been killing me slowly for two months now. I can't fase out our old
intranet without blogs.
If today's fix is still not working, I am very tempted to try the
post-SP1 hotfixes.

I'm not sure if you could even reproduce the problem. Other
webpplications on my farm don't have "<LOCAL SERVER>\Users" read
rights to the /bin directory and seem to function well. Go figure.
FileMon gave me a very direct hint today and helped me solve my 403
problems (for now or ever, ever, ever?).

Another influence may be the staging (MOSS) environments for some
(planned) public-facing MOSS sites, which contain custom development
(event receivers, masters, ect).

I am curious if you would find anything though...
Thanks for thinking along. (siging off for today)