share_a_pint

I recently installed the CTP of SharePoint Workspace 2010.  All was fine until I came across something I hadn't seen before. When ever I would go to a SharePoint site and try to Upload Multiple Files, I would be presented with a "Drag Files Here" window. So being curious, I tried dragging and dropping a file here. When I click OK, it would try to upload the file to my document library, but would fail.

After doing some research (there were no results for "Drag Files Here" and "SharePoint" at both Bing and Google), I decided that it must be due to SharePoint Workspace 2010 being installed.  I removed that and rebooted.  Upon reboot, the screen below still came up, but instead of the ActiveX box to drop the files into, I just had a Red X, as in it was unable to load that element of the page.

To fix this and return to the default Windows explorer-esque 'Upload Multiple Documents' file tree, I had to run a repair on Office 2007.

SQL Server 2008 R2, slated for a Community Technology Preview this summer, provides some clues as to new features that will be availabe with/in SharePoint 2010:

From: http://www.microsoft.com/sqlserver/2008/en/us/r2.aspx:

Add-in for Microsoft Office SharePoint 2010

Share & Collaborate with Confidence

SharePoint 2010 Management Console

Manage User-Generated Analytical Applications

Ok…I need a little feedback from the community on this one, please.  I applied service pack 2 and the April 2009 CU for MOSS and WSS last week. Today, I noticed that all of the content, farm-wide, is showing a last modified time stamp of 1 week ago, unless the file has been updated in the last week, in which case it does show the correct time.  I've verified this is the case in my dev farm as well.

For those of you who have applied Service Pack 2 and/or the April 2009 Cumulative Update, can you look and see if you can find any last modified times that date back to before the updates were applied?

Thanks!

 Bug?  Edit.aspx pages, Survey Branching and more…occurs after you have the August Cumulative Updates or later installed and have exported/imported a site

I've come across an interesting scenario that I believe may be a bug in SharePoint 2007. To summarize, if you meet the following conditions, you probably have this issue and don't even know it yet:

 

1. You have applied the August Cumulative Update or any cumulative update after that (October, December or February).
2. You have exported a site with STSADM using the -includeusersecurity switch
3. You have imported the site somewhere else in the same SharePoint farm.

 

If you answered yes to the above prerequisites, or think that you will ever need to export/import a site, keep reading!

 

On a farm that has the August Cumulative Update or later applied, perform the following steps:

4. Open a command prompt and run the following command:

Stsadm.exe –o export –url http://<portalname>/sites/<Sitename> -filename c:<filename.cmp> –includeusersecurity –versions 4

 



In essence, you are exporting the site to a file, including any security settings, and any versioning that is present.

5. Verify that the export completed with 0 warnings, 0 errors.
6. Back in Central Administration, go to Application Management > Create Site Collection.



7. Give the site a title and URL, and use the blank site template.
8. Add in the site collection owner, and press OK.
9. Once the site has been created successfully, return to the command prompt.
10. Run the following stsadm command:

 

Stsadm.exe –o import –url http://<portalname>/<sitename -filename c:<filename.cmp> –includeusersecurity –updateversions 1

 



 

11. Verify that the import completed successfully, with 0 warnings and 0 errors.
12. Browse to the site that was just imported, and go to Site Actions > Create.
13. Select Survey.
14. Enter “Branching Test” for the Name, and set Allow Multiple Responses to Yes. Press Next.
15. Enter text in the question field for question 1. Leave the answer type as choice.
16. Scroll to the bottom and press Next Question.
17. Enter text for question 2. Leave the question type as choice.
18. Scroll to the bottom and press next Question.
19. Enter text for the third question. Leave the answer type as choice.
20. Scroll to the bottom and press Finish.
21. Click on Question 1.
22. Scroll to the Branching Logic section at the bottom.
23. Create branching by changing “Jump To” from No Branching to Question 2 or Question 3
24. Click OK.
25. Click on Branching Test in the breadcrumb to return to the actual survey.
26. Choose “Respond to this Survey”
27. Select any of the responses, and press next.
28. You receive “Error: Access Denied”

Note: The survey is using an Edit.aspx page.

 

You are also unable to edit an announcement that you create:

29. From the site that has been exported and imported into a blank site, go to View All Site Content . Click Create.
30. Choose Announcements.



31. Enter a name and choose to display the list on the quick launch. Click Create.



32. Browse to your new announcement list.
33. Click New > New Item.



34. Enter a title and body, and press OK.
35. Choose the item dropdown menu for the list item you created, and click Edit Item.
36. You receive  Error: Access Denied.

 

Looking for more proof?  If the site that you exported originally had an Announcements list, as all sites created with the default Team Site template have, add an item to that pre-existing list and try to edit it. You can.  This "issue" only occurs when an object that uses the Edit.aspx page was created after its site was exported/imported and the August Cumulative Update or later has been applied.

 

Conclusion

I haven't been able to pinpoint what it is in the August update that causes this behavior. I suspect that it has to do with security, specifically dealing with sites that are using inherited permissions.  It doesn't seem to be an issue with what features are enabled – I've made sure that the destination site has the same features enabled that the source site does, prior to importing the site.  I had originally thought it had something to do with .net 3.5 SP1, but I've tested this over and over again, and it is not dependant on any specific .net level.

 

If you are curious, you can try this on the prebuilt MOSS VHD from Microsoft. The MOSS VHD, as of this writing, is patched to either the SP1 or Infrastructure levels. Create a site and test it out, and then update through the August Cumulative update and try again. My bet is that you'll get the error message too.

 

I'd be really interested to hear from anyone who has either run into this issue, or who can debunk this. In the end – I'm just looking for a way to resolve this without rebuilding entire site collections from scratch.

 

 

Ok…since December 26th, 2007, I've had an open support case with Microsoft Support in regards to some recurring errors that we were seeing in our SharePoint 2003 farm.  Every hour, between 4-6 times depending on which server you look at, each server in the farm would log the error with event ID 1000: #50070: Unable to connect to the database <configuration database name> on <Sql server name>.  Check the database connection information and make sure that the database server is running.

 Well, as you can imagine, we checked the connection, and it was fine.  We also checked everything else under the sun. Probably two or three times.  We recreated the configuration database, and the errors quickly returned. We brought in people from the SQL team, and ran some extensive logging of all of the activity that was occuring, and couldn't find anything.  We tried numerous hotfixes, and removed others that might have caused this as a side effect.

Finally, after 6 months, and numerous support engineers, I made the discovery by reviewing process monitor logs, that System Center Operations Manager was making a call on SharePoint at the same time that the errors were occuring.

A quick disable and stopping of the service showed that the errors stopped occuring.  So…if you have these tedious event id 1000 errors, don't forget to check on external monitoring services to see if they are the culprit, as SCOM was in my case.  It's nice to have a resolution to this. I thought I had stumped everyone at Microsoft.  Well…I guess I actually did stump them since I figured it out in the end.

"Microsoft has now found the root cause of this problem to be the IIS ADSI provider. Essentially, if you have a process with more than one thread and two threads access IIS 6.0 at the same time, then this issue occurs.  This problem is likely to occur for the SharePoint Timer service (OWSTimer.exe) in Microsoft Office SharePoint Server 2007. When this occurs, you may find that:

• In SharePoint Server 2007, tasks that are scheduled do not run.
• When you try to manage IIS 6.0 by using Server Manager, you receive a blank page, or you receive the following error message: "the path specified cannot be used at this time".

The Event ID's 7076, 6398 and 6482 and memory error messages described above will also be recorded in the Application Event Logs. Microsoft now has a KB article describing this problem http://support.microsoft.com/?id=946517 along with details of the fix and how to obtain it. This fix is not a SharePoint fix so you should be able to install the fix regardless of what Service Pack level you are running."

I have come across a problem with the Knowledge Base application template for MOSS / WSS v3 that is easily reproducible.

Summary of problem:  Links on the Knowledge Base site do not update to the new location when you import or restore the site from one location to another.

Steps to reproduce: 

1.  Create a site collection and top level site within it.

2.  Create a new subsite, and use the Knowledge Base application template.

3.  Backup the site using SharePoint Designer – or – export it using the STSADM -o export commands.

4. Move or copy the resulting files to your other SharePoint 2007 environment.

5. In the other SharePoint environment, create a site collection using the blank site template

6. Restore the site using SharePoint Designer – or – import is using the STSADM -o import commands.

7.  Browse to the site in the new location, and hover over the links in the quick launch for "Write an Article" or "Upload a Document".

Both of those links will not have changed, and will be referencing a location and GUID from the old site.

I hate having to tell my customers that they can create a site in development, but we can't move it to production for them.  Right now it seems to be that if you want to use the Knowledge Base template, you need to create it in its permanent location and never attempt to move it.

I'd be interested to hear if anyone else has run into this problem, or if anyone has come across the solution or workaround for this?

Thanks

Share~A~Pint