It has been pretty quiet around here but I’m trying to get some content up every now and then…
This was an issue I encountered recently with one of my clients. Their configuration datbase has grown up to 43GB and they couldn’t get it back to normal size which according to this TechNet Article is definied as small (~1GB) in size.
The first thing I have done to drill down into this issue was to open the disk usage by table report for the database within SQL management studio. This report showed me at the first glance that the timerjob history table size was very huge. Usually the timerjob history gets cleaned by a timerjob called “Delete job history” which by default runs every week
The next thing was to check the timerjob history in Central Admin and look for the last runs of this particular timerjob. And here I found the job failing for multiple weeks. When checking the error message it was pretty clear, the timerjob failed because the transaction log of the config db was full!!!
The next step was to check the settings for the transactionlogs in SQL server management studio and here I found the size of the transactionlog limited…After setting the size of the transactionlog to unlimited and running the timerjob the timerjob history table in the disk usage by table report shrunk back to a normal size and the database size could be normalized back to less than 1GB.
A good friend of mine Paul Grimley contacted me about this blogpost and highlighted that it would be helpful to update this article with some general guidance on database maintenance for SharePoint. Especially guidance on how we got the database size in the above described scenario back to normal.
In general I would recommend this TechNet article on SharePoint Database maintenance. It is for SharePoint 2010 but still valid for 2013. It also gives particular guidance on how to shrink data files.
Also I would like to share some articles Paul pointed me at which look at this topic from a supportability perspective:
- Support for changes to the databases that are used by Office server products and by Windows SharePoint Services (Please read this one very carefully!!!)
- Database Maintenance for Microsoft SharePoint 2010 Products
Plus extra Kudos to Paul for checking the delete history timerjob on his environment – which lead us to identify that the schedule of the timerjob has changed from weekly in SharePoint 2010 to daily in SharePoint 2013.
Hope this helps…
I found an interesting issue in one of my SharePoint 2013 environments related to following sites. When a regular user clicks on the “Follow” button displayed in the top right corner of the screen the user will get an error.
If you look into the ULS log you will find the following error:
SQL Database ‘Databasename’ on SQL Server instance ‘InstanceName’ not found. Additional error information from SQL Server is included below. Cannot open database “Databasename” requested by the login. The login failed. Login failed for user ‘Domain\Username’.
Interesting about this issue is, that the account which doesn’t have permission to open the database is the application pool identity of the portal webapplication in which the site lives which the user would like to follow.
The Mysites reside in a different webapplication then the site the user wants to follow.
After a little investigation I tried to set the “GrantAccessToProcessIdentity” for the mysite webapplication for the applicationpool identity of the webapplication where the site the user want to follow resides in.
For that I used the below Powershell, which grants the account specified connect permissions on the database level. (This was also used in my previous blogposts “PowerPoint / Word WebApps–PowerPoint / Word WebApp cannot open this presentation / document” and “Excel calculation services–The Workbook can not be opened” to grant the proper permissions)
$webApp = Get-SPWebApplication “YourWebapp”
After running this I double-checked the permission of the database in SQL and found the permissions granted to the account as expected. When the user now tries to follow a site everything works as expected.
I don’t know if this is the proper way to solve this issue, I have encountered it only once due to the fact that it is still very early in the SP2013 implementation timeframe, I just wanted to share my experiences with this issue and will continue to keep my eyes open. If you experience the same problems please let me know.
Recently I was with a client and encountered some very interesting behaviour on one of their SharePoint 2010 sites.
Lets assume you have a list containing data and a status list which visualizes some of the data of the list in form of an graphical KPI, now you place a status list webpart on one of you pages displaying the information from your status list… everything works just fine. Unfortunately clients don’t call me in to show me how fine things are working…My client wanted to place a second (and even more) status list webparts on the same page and here is what they experienced:
The webpart which was placed last on the page will continue to show you the status bar instead of your beloved KPI.
After some investigation I found that my client was running on the December 2011 CU:
I reproduced this issue on my local environment after putting the February 2012 CU on the issue was fixed (I put February on on purpose to see how far back this issue has been fixed…)
With SharePoint 2010 the idea of a “farm of farms” got introduced by this an SharePoint 2010 deployment is described which not only consists of a single farm but of multiple farms sharing special service applications among each other.
A very common scenario is to have a “resource- or service farm” hosting the shareable services and multiple “consumer- farms” consuming the services from it.
As you might know, not all SharePoint2010 service applications can be shared across farms.
These are the service applications shareable across farms:
- User Profile
- Managed Metadata
- Business Connectivity
- Secure Store
Please refer to this TechNet Article for more details.
If you are looking for details on how to configure it this article can give you a good indication on how to do it.
So far so well known… I encountered an interesting thing with one of my clients who is running a mulit-farm environment and has several services shared across multiple farms.
During maintenance work they had to stop the SharePoint services on their “service farm” (that be the farm providing services for other farms) and when trying to access any webapplications hosted on the other farms they encountered an error message with a corelation id.
After checking the ULS logs I found:
Exception occured while connecting to WCF endpoint: System.ServiceModel.EndpointNotFoundException: Could not connect to https://servername:port/serviceapplicationGUID/ProfilePropertyService.svc. TCP error code 10061: No connection could be made because the target machine actively refused it <IP Adress>. —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it <IP Adress>. at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception) — End of inner exception stack trace — at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context) at System.Net.HttpWebRequest.GetRequestStream() at System.ServiceModel.Channels.HttpOutput.WebRequestHttpOutput. GetOutputStream() — End of inner exception stack trace — Server stack trace: at System.ServiceModel.Channels.HttpOutput.WebRequestHttpOutput. GetOutputStream() at System.ServiceModel.Channels.HttpOutput.Send(TimeSpan timeout) at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel. HttpChannelRequest.SendRequest(Message message, TimeSpan timeout) at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout) at System.ServiceModel.Channels.SecurityChannelFactory`1. SecurityRequestChannel.Request(Message message, TimeSpan timeout) at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object ins, Object outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) Exception rethrown at : at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at Microsoft.Office.Server.UserProfiles.IProfilePropertyService. GetProfileProperties() at Microsoft.Office.Server.UserProfiles.ProfilePropertyServiceClient. <>c__DisplayClass1.<GetProfileProperties>b__0(IProfilePropertyService channel) at Microsoft.Office.Server.UserProfiles.MossClientBase`1.ExecuteOnChannel(String operationName, CodeBlock codeBlock)
SharePoint Web Services Round Robin Service Load Balancer Event: EndpointFailure Process Name: w3wp Process ID: 6428 AppDomain Name: /LM/W3SVC/728495272/ROOT-1-129866768378254013 AppDomain ID: 2 Service Application Uri: urn:schemas-microsoft-com:sharepoint:service:82f426f16fb14278811f7cdce8c9912c#authority= urn:uuid:b217762e94f442b6b1c5d89a864f2a11&authority= https://servername:Port/Topology/topology.svc Active Endpoints: 1 Failed Endpoints:1 Affected Endpoint: https://servername:Port/serviceappGUID/ProfileService.svc
Which tells me that when I try to access a site running on another farm (one which consumes the user profile service from the “services farm”) SharePoint tries to connect to the server this service runs on which is not accessible and for that gives you an error.
For me I draw the conclusion that it would be recommended to loadbalance the servers hosting your userprofile service application within your service farm to avoid that this server becomes the single point of failure.
I encountered an interesting issue today when I was scaling out a existing SharePoint 2010 farm. So after installing SharePoint, several language packs, service pack and CUs I successfully joined the server to the farm.
No issues so far.
When I was checking the “servers in farm” link within Central admin I found right next to my newly joined server a big red “Upgrade required” message. But it wasn’t highlighting what component it wants to have upgraded. Normally this component would also be highlighted in red.
So I double checked my installation and made sure that I had all components installed properly, I even ran the configuration wizard one more time. Still the same result.
So my next step was to force SharePoint to write me some upgradelogs and give me some more details on what it actually was missing.
For that I used the commandline psconfig:
psconfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures
Once it was done I checked Central admin for the upgrade status and found the upgrade failed as expected but now SharePoint wrote me some nice upgradelog which I could look into.
After checking the log I found a few errors telling me that SharePoint tries to upgrade databases located under a certain SQL alias but it could not find them.
So I fired up cliconfg and found the SQL alias not existing after adding it (and also adding it to the x64 version of cliconfg) I just re-ran the SharePoint configuration wizard and after checking the servers in the farm section in central admin tataaaaaa the server was added with a nice grey “no action required” right next to it.
And what is the key takeaway from this? If you use SQL aliases (which I am a pretty big fan of) make sure to have them configured consistent across all your servers and when you see a warning telling you that an “upgrade is required” don’t immediately think that you have to install software but also check your configuration.
After doing a migration from SharePoint 2007 to SharePoint 2010 for one of my clients I experienced a funny Search crawl error. My client had a webpart on their SharePoint 2007 environment which displays the recently changed documents on the site. Everything was working just fine in SharePoint 2007 and the migration to SharePoint 2010 was running successfully as well.
Once we configured a search crawl to index the content we encountered several issues in the crawl logs telling us that the site can’t be downloaded and for that can’t be crawled.
After we ensured that the crawl account had appropriate permissions on the webapplication I used a little move I pull from time to time to troubleshoot searrch crawl issues. I logged in as the crawl account and we found that when the crawl account accesses the site a threshold error gets thrown which tells us that the webpart is exceeding the allowed threshold of 5000 items (default setting for the webapplication).
You can adjust the threshold in the webapplication general settings in central administration I would not recommend it though because you open up the door for very severe performance issues within your environment. Rather I would recommend to rethink the way you query your data from SharePoint to be more performance efficient.
My client was using his account with administrative privileges to verify if everything was working as expected after the migration but for this account the threshold will not be applied. The crawl account just has read permissions to the content and for that wasn’t able to crawl the content due to the threshold.
After removing the webpart from the site(s) crawling was just working fine. The webpart will need to be replaced by one beeing a little bit more aware of the threshold in SharePoint 2010 .
A very interesting error crossed my way the last week, you will find it in your SharePoint crawl log and it looks somewhat like this:
Which tells you that you can not crawl SharePoint2010’s ganttview.aspx which is the gantt view you can create for task lists or project task lists.
As often you can find the answer to this issue in the Microsoft forums:
Here is the solution suggested in the post. (I tested it in my environment and after changing the registry key suggested in the solution (and an reboot) the error went away)
Go to Registry editor in your SharePoint indexing server.
Navigate the following path within the registry editor:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager
Find the ‘UserAgent‘ key and change to:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; MS-RTC LM 8; Tablet PC 2.0)
A restart of the server is required!
A big thank you goes out to the author of this solution ssaz in the Microsoft forums.