http://sharepointexperience.com/csschart/csschart.html

http://www.topsharepoint.com/

Nice thing is they are categorised and ranked!

The issue is that the VMware display drive has not been configured for Accelerated 3D Graphics. To resolve this issue, shut down the VM, then under VM > Virtual Machine Settings > Display check the Accelerate 3D Graphics check box and select OK. You should now be able to restart your VM and go into full screen mode.

The solution is actually under the Region and Language > Administrative tab. There is a section for the Welcome screen and new user accounts, click the Copy Settings… button, you’ll notice that the Input Language for the Welcome Screen and the New User Accounts is still English (United States) – US. This is not what we want. Select both the check boxes to copy your current settings to the Welcome Screen and New User Accounts and click OK. Log off and back on and there you have it you can log on using the expected keyboard behaviour.

Word Web App cannot open this document for viewing because of an unexpected error. To view this document, open it in Microsoft Word.

Error Id: 68d8674b-53ac-407c-bfd7-9ef2a2c16611, 201116105124532

1. If you are running the SharePoint / Office Web Apps on a VM that also has the domain controller, you’ll get this error. This is not a supported configuration for a production environment. As this is typical for a demo / development VM, then you can run the following PowerShell:

   $e = Get-SPServiceApplication | where {$_.TypeName.Equals(“Word Viewing Service Application”)}
   $e.WordServerIsSandboxed = $false
   $e.WordServerIsSandboxed
   

   #(Please use the below script for PowerPointServiceApplication – You need to enter “Y” for the answer of each cmd)
   Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedViewing $false
   Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedEditing $false
   

   In the server’s c:\windows\system32\inetsrv\config\applicationHost.config
   Add the line below in the end of the dynamicTypes.
   <add mimeType=”application/zip” enabled=”false” />
   

   IISRESET
   

2. If you are seeing events with an ID of 3760 (shown below), you have not given the service account running the Office Web Application Services sufficient access. Ensure that the account has the required permissions.

Reference:

http://blogs.msdn.com/b/opal/archive/2009/11/16/installation-notice-for-sharepoint-2010-public-beta.aspx

http://technet.microsoft.com/en-us/sharepoint/ff800847

If you want to be alerted or aware of updates then you can subscribe to the SharePoint Team Blog.

WAVE is a free web accessibility evaluation tool provided by WebAIM. It is used to aid humans in the web accessibility evaluation process. Rather than providing a complex technical report, WAVE shows the original web page with embedded icons and indicators that reveal the accessibility of that page.

http://wave.webaim.org/

http://sharepoint-sandbox.com/files/sharepoint2010features.mht

http://www.getmatchpoint.com/

Recently, I was working on updating the Windows SharePoint Service Help Search Accounts. The issue was that when the DEV, UAT and production farms where originally built the same service accounts were used for each environment. This is NOT best practice, so I went about changing DEV and UAT, leaving Production using the original accounts. The process of updating the service accounts is simple enough using STSADM:

stsadm –o spsearch –farmserviceaccount [domain\serviceaccount] –farmservicepassword [password]

stsadm –o spsearch –farmcontentaccessaccount [domain\serviceaccount] –farmcontentaccesspassword [password]

An issue arose where we used the original service account post-fixed with the environment e.g.

When trying to update the service accounts I kept getting the following message:

Basically, saying that the account being provided is not valid. If I did the same update through the Central Administration I got the following message:

The username and password entered are not valid.

After several rounds of changing the password, recreating the account and trying manually set the service account, it was discovered that SharePoint uses the sAMAccountName rather than the UPN when it passes credentials. The sAMAccountName has a 20 character limit for backward compatibility.

The work around is simple keep the service account names to less than 20 characters. An alternative approach, one that I’ve not tested yet is to use the following format for the account [service account]@[domain.com]. Anyway I hope that this will save you some time, I wish I had known this limitation before I embarked on updating the accounts.