"Related Content" link in work flow Task form does not open in browser

Below is the step by step procedure for solving the issue

1.Open C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\template\layouts.
2. Locate the WrkTaskIP.aspx.  Make a copy of the file and Open in sharepoint designer.
3.  Locate the line SPHttpUtility.NoEncode(m_pageDescription,Response.Output); remove this and add below code 
<%
if(m_pageDescription.Contains(".xml"))
{
//Forcing any xml items to open with forms services
SPHttpUtility.NoEncode(m_pageDescription.Replace("http",SPContext.Current.Web.Url+"/_layouts/FormServer.aspx?DefaultItemOpen=1&ClientInstalled=true&Options=DisableSave&XmlLocation=http"),Response.Output);
}
else
{ 
SPHttpUtility.NoEncode(m_pageDescription,Response.Output);
}
%>
4. Do save

 hope this helps..

Application Server Administration job failed for service instance. Event ID 6482

There were many issues that require you to clear the share point configuration cache on your servers.

Below is the step by step provided by Microsoft for Clearing Configuration Cache
1. Stop the Windows SharePoint Services Timer service (Found in Windows Services)
2. Navigate to the cache folder
Drive:\ProgramData\Microsoft\SharePoint\Config\<GUID>
There may be more than one  GUID folders
3. Locate the folder that has the file "Cache.ini"
4. Back up the Cache.ini file.
5. Delete all the XML configuration files in the GUID folder
Note : make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
6. Open Cache.ini file in Note Pad, click Select All and Delete. Type 1, and then Save. Close the Note Pad.
7. Start the Windows SharePoint Services Timer service
8. Restart IIS
Make sure that the Cache.ini file in the GUID folder now contains its previous value, not 1.

Resolving the super user/super reader account utilized by the cache is not configured

By default, the Portal Super User account is the site’s System Account, and the Portal Super Reader account is NT Authority\Local Service.

Give domain\superuser, Full control in user policy of the particular site from Central administration. And also for domain\superreader Full read permission in user policy.

If your web application is using claims based authentication the users should be displayed like i:0#.w|domain\superuser and i:0#w|domain\superreader.

To add the user accounts to the Web application by using Windows PowerShell
Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
Copy the following code and paste it into a text editor, such as Notepad:

$wa = Get-SPWebApplication -Identity "http://<server>/"
$wa.Properties["portalsuperuseraccount"] = "i:0#.w|domain\superuser"
$wa.Properties["portalsuperreaderaccount"] = "i:0#w|domain\superreader"
$wa.Update()

Save the file, naming it SetUsers.ps1. Close the text editor.

On the Start menu,Open SharePoint 2010 Management Shell. Change to the directory where you saved the file.At the Windows PowerShell command prompt, type the following command: ./SetUsers.ps1

After you've run these PowerShell cmdlets  perform an IISRESET to finish it off.

Limiting People Picker to a certain OU in Active Directory

If a Web application is using Windows authentication and the site user directory path is not set, the People Picker control searches the entire Active Directory to resolve users' names or find users, instead of searching only users within a particular organizational unit (OU). The Stsadm setsiteuseraccountdirectorypath operation allows the user's directory path to be set to a specific OU in the same domain. After the directory path is set to a site collection, the People Picker control will only search under that particular OU.
To restrict People Picker to a certain OU in Active Directory, type the following command:

stsadm -o setsiteuseraccountdirectorypath -path <Valid OU name> –url <Web application URL>

The following example configures People Picker to only return users and groups in the OU named "Sales":
stsadm -o setsiteuseraccountdirectorypath -path "OU=Sales,DC=ContosoCorp,DC=local" –url http://ServerName

Only a single site user directory path can be set at a time for a site collection. Because this property specifies only one OU at a time, you should run the Stsadm setsiteuseraccountdirectorypath operation only once per site collection.

To retrieve the current user account directory path for the site, use the following syntax:
stsadm -o getsiteuseraccountdirectorypath -url <Web application URL>

Work Flow is not updated. Showing as cancelled in work flow column

Sometimes this situation may happen, you are making changes to your SPD workflow and they are not reflected on the list/doc library where the workflow is deployed.

reason is that, SPD will use the cahced information from a location such as the following:

%System Drive%\%user%\Local\AppData\Microsoft\WebSiteCache

Here you will find a folder named similar to your SharePoint site on which you are working.

Delete this folder and restart SharePoint Designer and IIS. Make any changes to your workflow and that should be reflected onto your list/library.