Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Document Upload, fails, works later

  Asked By: Israel    Date: Jul 11    Category: Sharepoint    Views: 3265

We have a curious thing happening with some new users. In this
example: They create their new My Site then go to Shared Documents to
upload a file. When they select Upload, they get a "forbidden 403"
error. If they wait and try later many times they can upload a file.

Has anyone seen this before?

We talked to Microsoft Support yesterday and I'm going to try
escalating the call: Here is how we were troubleshooting the problem:
-----------------------

My Site file upload permission errors (similar to other portal upload
errors we've seen).

Per instructions with our Microsoft rep, we tested with two domain
accounts that had never been used on the portal before.

• MS had us add the new user to the mba portal manually and
give them contributor rights.
• We then selected the My Site, a new My Site was created.
• We tried to upload a document and received a "forbidden, 403"
error.
• We tried with another new test account and received the same
error.

MS wanted to have us test with a newly created Shared Service
Provider and New Portal. This was all done on our production server.

Approximately four attempts to create the SSP failed. We were
finally successful when we stopped and started the "Windows
SharePoint Services Timer" service on MOSS. We used our "farm
account" with all of the following:

• We created a new Shared Service Provider
• We created a new My Site application
• We created a new portal application.
• We assigned the new portal to the new SSP.
• We added our test account users to the site (we didn't import
domain users into this test shared service provider)
• We logged in with the test account, selected My Site,
creating a new My Site.
• We successfully uploaded a document.

At this point our MS support offered two suggestions:

• Since the second Shared Service Provider worked in our test,
MS Support requested that we re-assign our production portal to use
the new Shared Service Provider.

I would not do this. If I did, we would lose all our
audience and search settings. All our targeted portal content would
no longer be targeted and maybe other unknown side effects. If we
did go this route, I would need to configure this exactly as our
current SSP. I would want to do this on a separate server first to
make sure our production site is not adversely affected.

• Change domain accounts for all SharePoint portals, app pools,
shared service provider etc, to use a single account. Then we would
run a series of command line scripts to update the portal to
recognize the new account. "How to change the passwords for service
accounts in SharePoint Server 2007 and in Windows SharePoint Services
3.0"
We will not do this. We built our server with separate
accounts based on recommendations from Microsoft. We have the white
paper to back this up. http://technet2.microsoft.com/Office/en-
us/library/f07768d4-ca37-447a-a056-1a67d93ef5401033.mspx?mfr=true

Final thoughts:

• Even though MS Support had success with our test SSP, Portal
and My Site, we don't know if that site would also exhibit the same
random permission problems like the production site. Additionally,
the two accounts we tested with on the production server that failed
previously, work now. In the words of our own IT professional who
put it plainly:
================================================================
Dear MS Support:

Shortly after we finished our phone conversation with you we went
back to our production portal and all the user accounts we created
for your test were able to download documents. To recap, when we
first created the accounts and tried to upload a document, it
failed. But after a period of time we tried again and then the
accounts could upload a document.

My question is this. If our account is wrong as you say why does it
work after a short period of time? This is the problem we have had
with most people. If they fail to be able to load a document, all
they have to do is wait about 15 minutes or so then when they try
again they can now upload documents fine.

At this point, I'm having a hard time believing if we change the
accounts that are being used by the app pools that all our troubles
will go away. If indeed the accounts are wrong they why would the
accounts be ok after a 15 minute wait?

Share: 

 

1 Answer Found

 
Answer #1    Answered By: Donta Kirkland     Answered On: Jul 11

wanted  to send a follow-up about our My site  Document upload  problems
we've had. The problem  has gone away and we have closed the support
call with Microsoft.

In our final session with Microsoft we sent log files to analyze our
system. They came back with: "Remove the share to the MicroSoft.net
folder. Our developer had created  a share to this folder for his work.
At any rate, we removed the share and we have not had a problem since.
At the time it didn't make sense to me but the problem has not
re-occurred since we have done this.

After this I sent another set of log files that I thought may have been
involved in the problem . I asked if they could give us a reason for
the error message. They were not able to do so. This is the last
question I asked an explanation for:

Dear Microsoft support,

Good afternoon!

We have been talking over the permission  problems on our portal  and how
it may have been affected by the sharing of the MicroSoft.net folder.
We can't close this call  without knowing how the file  share could be
affecting the permissions. Steve and I will be doing more testing this
week with more new accounts  and we will send you an email this Friday to
let you know how it is going.

But, we really strongly stress that this problem seems to be time
related. If it doesn't work, wait for a period of time and eventually
it works. I captured log info on another user  experiencing this problem
on Aug 15th, previous to calling Microsoft support, and it had
information in it that lead me to believe there was a problem the first
time the My Site account  was created. I have attached the log file
pertaining to the user who experienced the problem.

failed to synch portal property FirstName during sweep synch.

failed to synch portal property LastName during sweep synch.

failed to synch portal property WorkPhone during sweep synch.

failed to synch portal property Office during sweep synch.

failed to synch portal property UserName during sweep synch.

failed to synch portal property WebSite during sweep synch.

08/15/2007 11:11:00.54 OWSTIMER.EXE (0x116C)

Likely this is a new site that doesn't have its schema pushed yet (will
occur at the next synch for this ContentDB). Exception follows:
System.NullReferenceException: Object reference not set to an instance
of an object. at
Microsoft.Office.Server.UserProfiles.ProfileCopier.CopyProfileToList(Use
rProfile up, SPListItem itm)

Consider this in the search  to an answer to our intermittent permission
problems.

Anyway... things seem fine now, and now you know the rest of our story.

 
Didn't find what you were looking for? Find more on Document Upload, fails, works later Or get search suggestion and latest updates.




Tagged: