Tuesday, July 8, 2008
The Ranch is Moving
We have saddled up and moved to our permanent home at http://thesharepointranch.com Come on by and sit a spell.
Monday, July 7, 2008
Saving a PDF from Adobe Reader to SharePoint
Well after much searching blogs, Forums, Google, and everything else I could find, I finally found a third-party plug-in that will let a person save PDF's to a SharePoint site. The tool is called Swiftwriter from Omtool http://Omtool.com With a little configuration, you have to specify your Default SharePoint site, all you do is click "Save to SharePoint" and you can then select you doc lib that you want to save to. There is one issue though, the tool doesn't seem to like sub sites for some reason and you can only specify one default SharePoint site. But if you can live with that this will work for you.
P.S. the tool says that it's designed for SharePoint 2003 but I have tested it using SharePoint 2007 and only had the problem with the sub sites.
P.S. the tool says that it's designed for SharePoint 2003 but I have tested it using SharePoint 2007 and only had the problem with the sub sites.
Monday, June 30, 2008
Shared Service Provider Database is excessively large
I
ran across this not to long ago. I found that there is a log table in that
database the records all changes to the UserPorfiles and keeps that history for
5 days. That is configurable through STSADM. Anyway once I truncated
that table and ran the shrink DB, it cleared up about 20GB. So take a
look at the Database and look for a table called UserProfileEventLog and see
how big it is. You can also right click on the DB and go to reports and
run the Disk Usage by top tables report. This will show you which table
are taking up all the space.
if the UserProfileEventLog Table is really big then you
can just truncate that table to decrease the size. They are just log
entries. You can also configure how many days of info that this save with
STSADM -o profilechangelog. Like I said before it defaults to 5
days. You might change that to 1 or 2.
UPDATE*********************************
Another client had a different table that was excessively large. The table in question this time was the ASPStateTempSessions table. According to some of the information I found this is also caused be the table not being truncated properly. This info did point to Project Server 2007 but seemed to apply to SharePoint as well since that's basically what Project Server 2007 is.
it http://support.microsoft.com/kb/317604
After installation of Office Project Server 2007, you need to remove expired session state data periodically from your Shared Services Provider database. This data is located in the ASPStateTempSessions table. This table needs to be truncated to ensure that expired sessions are deleted from the table. If this is not done, over time the accumulation of data in the database will affect server performance.
To remove expired data from the ASPStateTempSessions table:
Run the SQL Server Agent service to monitor the database.
Periodically truncate your ASPStateTempSessions table to remove expired session state data. You can run the following SQL script to delete data from the table:
use
truncate table ASPStateTempSessions
http://technet.microsoft.com/en-us/library/cc197479(TechNet.10).aspx
Monday, June 9, 2008
This Site: and This List: Search Scopes not working
If your "default" url in Alternate Access Mappings and the url used in the content source are different, then you will have this issue.
If your default URL is http://servername and you have an addtional URL for the same web app in the alternate access mappings, say http://sharepoint and if you use http://sharepoint in your content source, the crawl works fine without any errors but when searching via one of the contextual scopes (This Site:, This List), you will not get any results.
If your default URL is http://servername and you have an addtional URL for the same web app in the alternate access mappings, say http://sharepoint and if you use http://sharepoint in your content source, the crawl works fine without any errors but when searching via one of the contextual scopes (This Site:, This List), you will not get any results.
Wednesday, June 4, 2008
SharePoint SilverLight Navigation
I recently have been playing around with some SilverLight stuff for SharePoint and came across the Silverlight for SharePoint Blueprint.
I installed the Silverlight Navigation Controls, which by the way need a lot of additional work to get working correctly. See http://www.wssdemo.com/Blog/archive/2008/03/24/installing-the-sharepoint-blueprint-for-silverlight-silverlightpart.aspx and http://www.u2u.info/Blogs/Patrick/Lists/Categories/Category.aspx?Name=Silverlight%20BluePrint for additional information.
Anyway, after getting this to work I found that it only picks up if you are using a Publishing Web and only picks up Publishing Pages. What I wanted to see is the actual SharePoint Navigation in Silverlight. So this is where the fun began.
After diving into the code I found a couple of things.
First, the SiteMapProvider that it is using is the CurrentNavSiteMapProvider which is an instance of the PortalSiteMapProvider. This SiteMapProvider retrieves the links from the QucikLaunch SPNavigation collection.
Secondly, I found the following code that was limiting the Navigation to Publishing Webs.
PublishingWeb pubWeb = PublishingWeb.GetPublishingWeb(SPContext.Current.Web);
PublishingPage pubPage = pubWeb.GetPublishingPages()[pageNode.Url];
What to Do
So the first thing to do is replace the SiteMapProvider with on the will return the TopNavigationBar. I choose to use the CombinedSiteMapProvider since it acts exactly like the GlobalSiteMapProvider when the Web site in question is set not to inherit its global navigation.
Secondly, comment out the 2 lines of code mentioned above:
// -- get the sites
try
{
//PublishingWeb pubWeb = PublishingWeb.GetPublishingWeb(SPContext.Current.Web);
SiteMapNode startNode = portalSiteMapProvider.CurrentNode;
if (!startNode.HasChildNodes)
startNode = portalSiteMapProvider.CurrentNode.ParentNode;
foreach (SiteMapNode pageNode in startNode.ChildNodes)
{
// -- get reference to publishing page to retrieve description and image
// PublishingPage pubPage = pubWeb.GetPublishingPages()[pageNode.Url];
next change the references to the pubPage variable to pageNode since we just removed pubPage. Also you will need to change the properties that are being returned by the pageNode.
if (pageNode != null)
{
// -- add the page node with title and url
XmlNode xmlnode = xmlDoc.CreateElement("Page");
XmlAttribute titleAttribute = xmlDoc.CreateAttribute("Title");
titleAttribute.Value = pageNode.Title;
xmlnode.Attributes.Append(titleAttribute);
XmlAttribute urlAttribute = xmlDoc.CreateAttribute("Url");
urlAttribute.Value = siteUrl + pageNode.Url;
xmlnode.Attributes.Append(urlAttribute);
siteNode.AppendChild(xmlnode);
if (pageNode != null)
{
XmlAttribute descriptionAttribute = xmlDoc.CreateAttribute("Description");
if (pageNode.Description != null)
descriptionAttribute.Value = pageNode.Description.ToString();
else
descriptionAttribute.Value = "";
xmlnode.Attributes.Append(descriptionAttribute);
XmlAttribute imageAttribute = xmlDoc.CreateAttribute("Image");
Next I commented out the code applying the page image to the menu items. (NOTE: Still trying to figure out how to get the site image to load here)
/* if (mysite.SiteLogoUrl.ToString() != null)
{
string imageHTML = mysite.SiteLogoUrl.ToString();
XmlDocument imdoc = new XmlDocument();
imdoc.LoadXml(imageHTML + "");
if (imdoc.DocumentElement.Attributes.GetNamedItem("src") != null
&& imdoc.DocumentElement.Attributes.GetNamedItem("src").Value != null)
imageAttribute.Value = siteUrl + imdoc.DocumentElement.Attributes.GetNamedItem("src").Value;
} */
/* else if (pubPage.ListItem["PublishingRollupImage"] != null)
{
string imageHTML = pubPage.ListItem["PublishingRollupImage"].ToString();
XmlDocument imdoc = new XmlDocument();
imdoc.LoadXml(imageHTML + "");
if (imdoc.DocumentElement.Attributes.GetNamedItem("src") != null
&& imdoc.DocumentElement.Attributes.GetNamedItem("src").Value != null)
imageAttribute.Value = siteUrl + imdoc.DocumentElement.Attributes.GetNamedItem("src").Value;
}*/
That's it. The Silverlight Navigation Bar will now show you the Site Navigation rather then just publishing pages.
Error during encryption or decryption. System error code 997
I had this exact same problem below and copied the post to here for further reference. Click here for the origianl post:
http://www.whitworth.org/Blog/PermaLink,guid,f0c3c8b0-bfb8-4796-b130-dcc7175ce2e4.aspx
I was recently installing WSS 3.0 on a SQL Reporting Services server to prepare it for Sharepoint Integrated Mode and got an error similar to the following at the end of the Sharepoint Technologies Configuration Wizard:
Error during encryption or decryption. System error code 997
After reading the article included below, I realized our problem was that we changed the sharepoint service account password nearly a month ago. Everything still appeared to be working fine, but when I went to join a new server to the farm it was still trying to receive the incorrect credentials that were cached. In a nutshell, you have to run stsadm -o updatefarmcredentials on the central admin server (with the correct parameters below) and then also update the credentials on the server that failed to join, then go back and do one more update on the central admin server. I also disconnected it from the farm and reconnected it after the failure.
I found the following article on the Centricity Web Site. My apologies for the direct copy, but this was useful info I did not want to lose.
I was adding a secondary web front-end to their already existing Production MOSS 2007 Farm for one of my clients. The MOSS 2007 RTM software was installed using the "Complete" option ("Web Front-end" only option was tried as well with the same results) on a newly created server.
Each time I attempted to run the "SharePoint Products & Technology Configuration (SPTC)", I received the an error stating to the server could not be added and that I should review the PSC_Diagnostics.log file. The actual error is shown below.
Most Common Advice is not always the "Best Advice"
The error code (997), as well as a number of SharePoint professionals, pointed me to a Knowledge Base Article (http://support.microsoft.com/kb/927156)
This article simply says to recreate you configuration database, using the following command line.
psconfig -cmd configdb -create -server ServerName -database ConfigDBName -user Domain\User -password Password
Expected Outcome
By doing this, expect to loose time and everything but content. You will have to do the following to properly recover:
Recreate each web application and reattach the existing content database.
Recreate the Shared Services Provider web application and reattach that database.
Re-add each web front-end and application server to the farm.
Research Found
Jukka Paajanen [MSFT] on EggheadCafe associates the error code (997) with a few other issues and provides the problem. He says the issues are:
the error number is 997
have standalone install (or have configured your farm with account that has no password or the account password changed)
one of the SharePoint services used an account that has password (web app, services)
are reinstalling,
The Problem, he states is "the existing configdb has old references to passwords that it cannot decrypt."
His Solution was to do the same as above.
Better Solution
Well, my problem is fixed and I did not recreate my configdb. It is much simpler. At the time this article was written no one other than Jukka had made the association between changing passwords and the error code (997). This lead me to look into resetting farm credentials, which led me this article by Joel Oleson
Joel Oleson outlines the process in detail:
----------------------------
If you know the password before the password change, you can do the following to your machine with WSS on it:
Ensure the WSS Administration and WSS Timer services are running on all machines.
On machine with central admin (WFE1)
stsadm -o updatefarmcredentials -userlogin "domain user" -password "newPassword"
iisreset /noforce (optional)
On any machine after this completes (wait for the "Administration Application Pool Credential Deployment" job definition to go away on the Timer Job Definitions central admin page)
stsadm -o updateaccountpassword -userlogin "domain user" -password "newpassword" -noadmin
Otherwise, after a password change:
Go to the server central admin box:
run the command stsadm –o updatefarmcredentials –userlogin -password
User must run IISReset /noforce to complete the action.
Delete the updatefarmcredentials timer job on central admin page->operations->job definitions page
Go to each other server in the farm, and run the command:
stsadm –o updatefarmcredentials –userlogin -password -local.
If –local isn’t supplied, it will fail because step (4) created a timer job that locks creating OTHER timer jobs.
On any machine after this completes (wait for the "Administration Application Pool Credential Deployment" job definition to go away on the Timer Job Definitions central admin page)
stsadm -o updateaccountpassword -userlogin "domain user" -password "newpassword" -noadmin
More verbose Instructions from MSIT. Note these are not really polished, but a have some integrated tips that should be of value.
Password Changes
WSS WFEs
Central Admin AppPool (First)
Stsadm –o updatefarmcredentials –userlogin -password
Other AppPools
Stsadm –o updateaccountpassword –userlogin -password [-noadmin]
Use –noadmin if the Central Admin AppPool is the same account as other Web AppPools
http://www.whitworth.org/Blog/PermaLink,guid,f0c3c8b0-bfb8-4796-b130-dcc7175ce2e4.aspx
I was recently installing WSS 3.0 on a SQL Reporting Services server to prepare it for Sharepoint Integrated Mode and got an error similar to the following at the end of the Sharepoint Technologies Configuration Wizard:
Error during encryption or decryption. System error code 997
After reading the article included below, I realized our problem was that we changed the sharepoint service account password nearly a month ago. Everything still appeared to be working fine, but when I went to join a new server to the farm it was still trying to receive the incorrect credentials that were cached. In a nutshell, you have to run stsadm -o updatefarmcredentials on the central admin server (with the correct parameters below) and then also update the credentials on the server that failed to join, then go back and do one more update on the central admin server. I also disconnected it from the farm and reconnected it after the failure.
I found the following article on the Centricity Web Site. My apologies for the direct copy, but this was useful info I did not want to lose.
I was adding a secondary web front-end to their already existing Production MOSS 2007 Farm for one of my clients. The MOSS 2007 RTM software was installed using the "Complete" option ("Web Front-end" only option was tried as well with the same results) on a newly created server.
Each time I attempted to run the "SharePoint Products & Technology Configuration (SPTC)", I received the an error stating to the server could not be added and that I should review the PSC_Diagnostics.log file. The actual error is shown below.
Most Common Advice is not always the "Best Advice"
The error code (997), as well as a number of SharePoint professionals, pointed me to a Knowledge Base Article (http://support.microsoft.com/kb/927156)
This article simply says to recreate you configuration database, using the following command line.
psconfig -cmd configdb -create -server ServerName -database ConfigDBName -user Domain\User -password Password
Expected Outcome
By doing this, expect to loose time and everything but content. You will have to do the following to properly recover:
Recreate each web application and reattach the existing content database.
Recreate the Shared Services Provider web application and reattach that database.
Re-add each web front-end and application server to the farm.
Research Found
Jukka Paajanen [MSFT] on EggheadCafe associates the error code (997) with a few other issues and provides the problem. He says the issues are:
the error number is 997
have standalone install (or have configured your farm with account that has no password or the account password changed)
one of the SharePoint services used an account that has password (web app, services)
are reinstalling,
The Problem, he states is "the existing configdb has old references to passwords that it cannot decrypt."
His Solution was to do the same as above.
Better Solution
Well, my problem is fixed and I did not recreate my configdb. It is much simpler. At the time this article was written no one other than Jukka had made the association between changing passwords and the error code (997). This lead me to look into resetting farm credentials, which led me this article by Joel Oleson
Joel Oleson outlines the process in detail:
----------------------------
If you know the password before the password change, you can do the following to your machine with WSS on it:
Ensure the WSS Administration and WSS Timer services are running on all machines.
On machine with central admin (WFE1)
stsadm -o updatefarmcredentials -userlogin "domain user" -password "newPassword"
iisreset /noforce (optional)
On any machine after this completes (wait for the "Administration Application Pool Credential Deployment" job definition to go away on the Timer Job Definitions central admin page)
stsadm -o updateaccountpassword -userlogin "domain user" -password "newpassword" -noadmin
Otherwise, after a password change:
Go to the server central admin box:
run the command stsadm –o updatefarmcredentials –userlogin
User must run IISReset /noforce to complete the action.
Delete the updatefarmcredentials timer job on central admin page->operations->job definitions page
Go to each other server in the farm, and run the command:
stsadm –o updatefarmcredentials –userlogin
If –local isn’t supplied, it will fail because step (4) created a timer job that locks creating OTHER timer jobs.
On any machine after this completes (wait for the "Administration Application Pool Credential Deployment" job definition to go away on the Timer Job Definitions central admin page)
stsadm -o updateaccountpassword -userlogin "domain user" -password "newpassword" -noadmin
More verbose Instructions from MSIT. Note these are not really polished, but a have some integrated tips that should be of value.
Password Changes
WSS WFEs
Central Admin AppPool (First)
Stsadm –o updatefarmcredentials –userlogin
Other AppPools
Stsadm –o updateaccountpassword –userlogin
Use –noadmin if the Central Admin AppPool is the same account as other Web AppPools
The Server is not Operational in Event Log on SharePoint Web Servers
Wow this one was a major tough one. Thanks to one of my colleagues for figuring it out.
We have a SharePoint farm consisting of 3 Front-ends, 1 Index server, and Cluster SQL 2005. The 3 Front-ends are using Microsoft NLB (WHICH IS EVIL BY THE WAY)! Anytime we got high usage on the front-ends we were slammed with "Server is not Operational" in the Application event log. Since the SharePoint site is using Forms Authentication we originally thought it was a problem with the LDAP provider. But couldn't make the case for that. After extensive searching my colleague found an older article about TCP wait time. Here is the link to that article.
http://www.port80software.com/200ok/archive/2004/12/07/205.aspx
It appears what was happening is that with all the flooding that happens with MS NLB it was causing issues with the connection the AD during heavy use periods. My colleague made this change on each front-end:
You must add the Tcp TimedWaitDelay REG_DWORD value to the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters registry subkey. Then, you set the delay to the number of seconds (in decimal form):Value Type: REG_DWORD-- Time in secondsValid Range: 30300 (decimal)Default: 0xF0 (120 decimal)http://windowsitpro.com/article/articleid/23276/the-time_wait-states-effect-on-iis-performance.html This decreased the wait time reset value from 4 minutes to 2 minutes. After monitoring the system for a couple of days, Whala! No more errors. I sure hope this helps someone else out there!
We have a SharePoint farm consisting of 3 Front-ends, 1 Index server, and Cluster SQL 2005. The 3 Front-ends are using Microsoft NLB (WHICH IS EVIL BY THE WAY)! Anytime we got high usage on the front-ends we were slammed with "Server is not Operational" in the Application event log. Since the SharePoint site is using Forms Authentication we originally thought it was a problem with the LDAP provider. But couldn't make the case for that. After extensive searching my colleague found an older article about TCP wait time. Here is the link to that article.
http://www.port80software.com/200ok/archive/2004/12/07/205.aspx
It appears what was happening is that with all the flooding that happens with MS NLB it was causing issues with the connection the AD during heavy use periods. My colleague made this change on each front-end:
You must add the Tcp TimedWaitDelay REG_DWORD value to the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters registry subkey. Then, you set the delay to the number of seconds (in decimal form):Value Type: REG_DWORD-- Time in secondsValid Range: 30300 (decimal)Default: 0xF0 (120 decimal)http://windowsitpro.com/article/articleid/23276/the-time_wait-states-effect-on-iis-performance.html This decreased the wait time reset value from 4 minutes to 2 minutes. After monitoring the system for a couple of days, Whala! No more errors. I sure hope this helps someone else out there!
Access Denied checking out Master Page and other strange permission issues
We are having some very strange permissions problems with one of our customers. First off all of the document libraries, and lists in the entire Site Collection and sub sites do not show the Settings Button menu. You can still get to the settings through all Site Settings, Site Administrations and then Customize the the Content.
As well when going to a doc lib or list the "Edit Page" under site actions are missing.
I have also tried to just check out any of the pages in the Master Page Gallery and receive and "ACCESS DENIED" page.
We have tried several different users all having Site Admin, Designers, Full Control permissions. I have even checked to ensure that there are no unique permission set on these lists or doc libs.
I also created a new sub site with Unique permissions and still have the same issues. Appears to be something with Web Application but I can't find what the problem is.
************************ UPDATE ************************************
Oh what an idiot I am. Never occurred to me to look in the most obvious place.
Check what you currently have as the' User Permissions for the Web Application' by going to Central Administration -> Application Management (for the pertinent Web Application) -> User Permissions for Web Application (Under Application Security Category) and see if all permissions here are checked. If not, they will not filter down to any of the Site Collection permissions.
As well when going to a doc lib or list the "Edit Page" under site actions are missing.
I have also tried to just check out any of the pages in the Master Page Gallery and receive and "ACCESS DENIED" page.
We have tried several different users all having Site Admin, Designers, Full Control permissions. I have even checked to ensure that there are no unique permission set on these lists or doc libs.
I also created a new sub site with Unique permissions and still have the same issues. Appears to be something with Web Application but I can't find what the problem is.
************************ UPDATE ************************************
Oh what an idiot I am. Never occurred to me to look in the most obvious place.
Check what you currently have as the' User Permissions for the Web Application' by going to Central Administration -> Application Management (for the pertinent Web Application) -> User Permissions for Web Application (Under Application Security Category) and see if all permissions here are checked. If not, they will not filter down to any of the Site Collection permissions.
SharePoint Portal administration service was not starting
I have now experienced this issue at multiple customers so wanted to get this out there.
Problem:=========
After Installing few Windows server 2003 updates, SharePoint Portal administration service was not starting on all Sharepoint servers.
Environment:===========
Sharepoint Portal server 2007Medium server farm
Resolution:=========
We changed following registry settings on the Sharepoint servers:
Added:HKLM\SYSTEM\CurrentControlSet\Control change DWORD value ServicesPipeTimeout and assign 60000 (i.e. 60 thousand which means 60 seconds)
Modified:Increse value of in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control string value WaitToKillServiceTimeout to 120000 (120 thousand which means 120 seconds)
Rebooted the server.
Found that Sharepoint portal Administration service is running fine on the server.
Problem:=========
After Installing few Windows server 2003 updates, SharePoint Portal administration service was not starting on all Sharepoint servers.
Environment:===========
Sharepoint Portal server 2007Medium server farm
Resolution:=========
We changed following registry settings on the Sharepoint servers:
Added:HKLM\SYSTEM\CurrentControlSet\Control change DWORD value ServicesPipeTimeout and assign 60000 (i.e. 60 thousand which means 60 seconds)
Modified:Increse value of in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control string value WaitToKillServiceTimeout to 120000 (120 thousand which means 120 seconds)
Rebooted the server.
Found that Sharepoint portal Administration service is running fine on the server.
Subscribe to:
Posts (Atom)
Posts
