Archive | SharePoint Infrastructure RSS for this section

UPDATED: Gigantic Config DB… why… and how to get it back to normal

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.

UPDATE:

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:

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…

Advertisements

SharePoint 2010 multi farm high availability consideration

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
  • Search
  • Secure Store
  • Webanalytics

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 [0]:      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)

and

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.

“Upgrade required” and missing SQL aliases a funny little fact

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.

SharePoint UPS SyncDB Maintenance

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
DeleteObjectReferences  

x

mms_getmvobjecttype  

x

mms_GetObjectIDsForCSLinkIDs  

x

mms_getrowwithrdnpobjid

x

 

mms_getrowwithrdnpobjid_holdlock

x

 

mms_getrowwithrdnpobjid_xlock

x

 

mms_getrowwithrdnpobjidfast

x

 

TruncateInstanceData

 

x

TruncateObjectsInternal

 

x

TruncateSystemObjects

 

x

Stuff2Read: Sandboxed solutions service

This time I was digging a little bit deeper in the sandboxed solutions topic and especially in the configuration of resource points and service tiers.

Here are some interesting reads on those topics:

Resource Usage Limits on Sandboxed Solutions in SharePoint 2010
Configure resource points for sandboxed solutions (SharePoint Server 2010)
Nice overview on sandboxed solutions service tiers
Configure sandboxed solutions service tiers (SharePoint Server 2010)

EventID 6398 – Attempted to perform an unauthorized operation

And another EventID 6398 which colors your eventlog red.

 The Execute method of job definition Microsoft.SharePoint.Diagnostics.SPDatabaseServerDiagnosticsPerformanceCounterProvider (ID ) threw an exception. More information is included below.

Clustername:Attempted to perform an unauthorized operation.;DB_Name:Attempted to perform an unauthorized operation.;DB_Name:Attempted to perform an unauthorized operation.;DB_Name:Attempted to perform an unauthorized operation.;DB_Name:Attempted to perform an unauthorized operation.;DB_Name:Attempted to perform an unauthorized operation.;DB_Name:Attempted to perform an unauthorized operation.;

Please ensure that the database server is available and that the SharePoint Timer service account is a member of the Performance Monitor Users group on the database server

image

To get rid of this error

1. Navigate the databases mentioned in the error.

2. Open the group “Performance Monitor Users” from the server groups (Mentioned in the error as well).

3. Add the user mentioned in the error to the group.

Do your “Removed an error from the eventlog happy dance”

EventID 5586 – Could not find stored procedure ‘proc_UpdateStatisticsNVP’

After installing SharePoint 2010 Service Pack 1 you might find an Error in your eventlog with the EventID 5586.

image

After some investigation and referring to Microsoft it seems that there currently is no solution or even a workaround for this error, which makes you hope for an fix in an CU or even Service Pack 2. Bummer 😦