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…
This is something I stumbled across recently… I wanted to retrieve a specific type of sites and their owners, when I checked the output of my script I figured that some sites seemed not to have siteowners, which irritated me a little. So I went to Central Admin checked the sites in the “View all sitecollections” area and found owners assigned to the sites. After fiddling around with PowerShell I figured out that if your site is set read-only you cant retrieve the siteowner anymore.
In the below PowerShell window you can see that I get a site and retrieve the owner from it. After that I set the site to be read-only, when I now retry to retrieve the owner I don’t get any information back. Once I set the read-only mode to false again the retrieval of the siteowner is working as expected.
I noticed this behavior in a SharePoint 2010 environment first and reproduced it in a SharePoint 2013 environment (from which I took the below screenshots).
If you look at the site in SharePoint 2013 you will be notified about the read-only status of your site.
In my special case I worked around it by retrieving the sitecollection administrators as I just needed somebody to contact but if you are really looking for that owner (or secondary owner) you might want to put a little bit more logic to your scripts to handle read-only sites.
“Database is up to date, but some sites are not completely upgraded” – and the journey to straighten things out
I faced an interesting thing in the SharePoint environments of one of my customers the other day…obviously the cool stuff never happens on your local environments .
This customer had patched their environment lately, everything was running smooth, nobody was complaining about anything, then, by incident, I checked the databasestatus.aspx page in central admin and found some databases marked with:
“Database is up to date, but some sites are not completely upgraded”.
So my first idea was, because they had a awful lot of databases in this state, to loop through all the databases and perform an upgrade-spcontentdatabase on the ones which contain not upgraded sites.
After running the script I found nothing changed on the UI (turns out if you do an IIS reset or an AppPool recycle this changes quite quickly). So after doing an IIS reset on the CA box I found some databases in the desired state “No action required” others though still in the same state.
So I checked the upgradestatus.aspx in the CA and found some warnings and errors for the databases containing sites which are not upgraded in the referenced upgrade logs. The most warnings I saw stated that
“Feature could not be upgraded. Exception: Unable to access web scoped feature (id: FeatureID) because it references a non-existent or broken web (id: webID) on site “siteurl”. Exception: System.ArgumentException: Value does not fall within the exptected range.”
When I checked the mentioned site and searched for the specific web I found this web existing in the recycle bin of the site.
So my next step was to create a PowerShell script to loop through all the sites and figure out which sites contain web objects in their recycle bin.
Once I have done that I created another PowerShell script removing all the webs from the recycle bin of the affected sites.
After that I ran my upgrade script again and found all databases in the “No action required” state except for two.
The first one was easy, this database was taken offline and for that couldn’t be upgraded.
For the second one I found Errors in the upgrade logs telling me:
Exception: Attempted to perform an unauthorized operation.
at Microsoft.SharePoint.SPSite.set_AllowDesigner(Boolean value)
at Microsoft.SharePoint.Portal.Upgrade.AllowMasterPageEditingAction.Upgrade(SPSite site)
This confused me because I knew that my customer had SharePoint Designer disabled for this webapplication.
After some asking around it turned out this wasn’t always the case, they had it enabled for a short timeframe… So my assumption is one of their sitecollection administrators must have enabled SharePoint Designer on his or her site during that short timeframe and maybe even modified something with it… scary huh?
Now SharePoint Designer being disabled on webapplication level SharePoint seems to have a little problem with that when performing upgrade operations on this site.
To overcome this issue I enabled SharePoint Designer for the webapplication and rerun my upgrade script again and afterwards disabled the SharePoint Designer settings again on the webapp level. After that I had all databases in every SharePoint Admins favorite state “No action required”
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.
When I was reading Spencer Harbar’s blogpost on User Profile Service Application Sync Database Maintenance with the February 2012 Cumulative Update I was curious about what exactly will be changed storeprocedure-wise when you deploy the February 2012 CU. So before patching one of my test-environments I decided to do a simple check up front to see what is there storeprocedure-wise and compare it to the same output after the installation of the CU.
I found a nice blogpost on how to extract the StoreProcs of a database by David Cumps (here).
Here is the output of my comparison (As Spencer mentions in his blogpost there is a lot of updating of existing storeprocs and even the db schema update) I was just curious about what has been removed and what has been added.
|Store Procedure||Removed with CU||Added with CU|
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.