Live Mesh is now open to everyone in the US
July 16, 2008Great News!
Live Mesh is now open to everyone in the US according to LiveSide
http://www.liveside.net/blogs/main/archive/2008/07/16/live-mesh-is-indeed-now-open.aspx
Great News!
Live Mesh is now open to everyone in the US according to LiveSide
http://www.liveside.net/blogs/main/archive/2008/07/16/live-mesh-is-indeed-now-open.aspx
The SharePoint administrator for our client recently changed teams. She was still receiving all the access request emails and wanted us to move it to another user. This took quite a bit of snooping around, since the option is not available front and center in the Site Settings page. We looked at all the security groups and checked to see if there were any access request emails set up on the groups. All those groups looked fine, but she was still getting those emails. Then we looked at the site permissions and sure enough there was an option under Settings called Access Requests with her email in it.

Our environment had 2 front end servers with MOSS 2007. The single sign-on service was leveraged within the web parts and everything worked fine on one server. However the following message was found in the event log on the second front-end server.
Event Type: Error
Event Source: Office SharePoint Server
Event Category: SSO
Event ID: 6494
Date: 7/1/2008
Time: 2:43:21 PM
User: N/A
Description:
The Microsoft Single Sign-on (SSOSrv) service failed to store credentials for user <DOMAIN\UserName>, enterprise application definition postini. The error returned was 0×8063064a. For more information, see the Microsoft SharePoint Products and Technologies Software Development Kit (SDK).
Resolution:
The Microsoft Single Sign-On Service was running as “LocalSystem” on the second server. Once we changed that to run as the MOSS 2007 application pool account, everything started working back as usual.
After installing SQL Reporting Services on our Web front end servers, our Sharepoint site crashed and burned with the following error in the event log
Unhandled exception was caught:
System.Configuration.ConfigurationErrorsException: Could not load file or
assembly ‘RSSharePointSoapProxy, Version=9.0.242.0, Culture=neutral,
PublicKeyToken=89845dcd8080cc91′ or one of its dependencies. The system
cannot find the file specified. (c:\inetpub\wwwroot\web.config line 6
—>
System.IO.FileNotFoundException: Could not load file or assembly
‘RSSharePointSoapProxy, Version=9.0.242.0, Culture=neutral,
PublicKeyToken=89845dcd8080cc91′ or one of its dependencies. The system
cannot find the file specified.
File name: ‘RSSharePointSoapProxy, Version=9.0.242.0, Culture=neutral,
PublicKeyToken=89845dcd8080cc91′
We had just installed the SharePoint Reporting Services add-in , so were sure that the necessary assemblies were on the server, since there were no errors during the installation. However we noticed that the installation was done with a non-admin account.
Resolution:
Running the installation using the same service account as the SharePoint application pool resolved the issue
After setting up SQL Reporting Services in SharePoint Integrated mode, trying to access the Report Server site using http://<remoteserver>:8080/ReportServer gave 401 errors. One weird thing that we noticed was when trying to set authentication to NTLM on our IIS web site, our values were getting reset to Anonymous access. A quick Google search brought up this post, which had the fix for the issue
Resolution:
Run the following from a command prompt within the C:\inetpub\AdminScripts folder
cscript adsutil.vbs set w3svc/NTAuthenticationProviders “NTLM”
Here is the link to the post
http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1379070&SiteID=17
When trying to set the Web Service Identity within the Reporting Services Configuration Manager in a SharePoint integrated mode , we encountered the following issue
ReportServicesConfigUI.WMIProvider.WMIProviderException: An unknown error has occurred in the WMI Provider. Error Code 80070003
at ReportServicesConfigUI.WMIProvider.RSReportServerAdmin.SetWebServiceIdentity(String applicationPool)
At first we thought the WMI provider was corrupted and tried to go that route for resolving this issue. After quite some time we figured that it may have been something with the applicationPool and hence started looking at the Web site configuration within IIS. Sure enough, in the ASP.NET tab for the web site, there was no entry for the ASP.NET version. After setting the value to 2.0 , we re-ran the configuration and the issue was fixed.
Resolution:
Check to make sure the right ASP.NET version is selected on your Reporting services website. While you are there ensure that the ASP.NET web service extension is set to Allowed. If these dont fix your issue running the aspnet_regiis -i might help as well ( I havent tried this!)
I got this email yesterday from the Live Mesh team
Fixes
Live Mesh is now available in all English-speaking countries (not just the U.S.)
Removed the User Account Control (UAC) requirement when installing and using Live Mesh with Windows Vista SP1
Index for Desktop Search now works with Live Mesh folders
Fixed bug where an underscore in a Hotmail account name returned an “Invalid Hotmail Address” error
Fixed bug with Silverlight 2 Beta 2 failing to load in Silverlight Media View
Fixed bug where the notifier tooltip incorrectly indicated that Live Mesh Remote Desktop was unavailable for a computer running in non-admin mode
Fixed bug where the Live Mesh folder icon was not displayed in the e-mail inviting someone to share a folder
Fixed one of the bugs that caused Live Mesh to fail to start
Fixed problem with Live Mesh returning errors when waking from sleep/hibernate
It is great news that UAC is no longer required!
I blogged here about not being able to install Live Mesh on Windows Server 2008, which I am running as my main workstation.
MsftGuy has a solution for this issue. Basically you run the LiveMesh.exe from the command line with the -force argument.
Thanks for the tip! Helped me a lot
http://msftguy.blogspot.com/2008/06/befriending-live-mesh-and-server-2008.html
When trying to setup email enabled document libraries, we setup the front end server with the SMTP service. On sending emails we saw the emails getting deposited into the C:\Inetpub\MailRoot\Drop folder. However the emails were not getting picked up and routed to the service. We tried to restart the Timer Service, gave folder permissions and nothing seemed to work. Upon checking the event logs we found the following entries
A critical error occurred while processing the incoming e-mail drop folder.
The error was: Value cannot be null. Parameter name: path.
Source: Windows SharePoint Services 3
Category: EMAIL
Event ID: 6872;
2)
“The Execute method of job definition
Microsoft.SharePoint.Administration.SPIncomingEmailJobDefinition (ID
d7c219ba-839d-4580-adc2-fa512a8cb833) threw an exception. More information is
included below.
Value cannot be null.
Parameter name: path”
Source: Windows SharePoint Services 3
Category: TIMER
Event ID: 6398″
This looked like the incoming email drop folder was not setup properly in the Central Admin Console. We checked and sure enough the drop folder was empty. Setting that value fixed this error. To set the drop folder
Central Admin-> Incoming email settings
Click Advanced and type in the email drop folder.

Here is a great whitepaper on how to setup incoming emails (Whitepaper)
Pavlov’s got a great post on AllowUnsafeUpdates and Cross-site scripting. A must read for all SharePoint developers.
http://hristopavlov.wordpress.com/2008/05/16/what-you-need-to-know-about-allowunsafeupdates/