Tag Archives: Logs

Why you should keep your on premise SharePoint when developing for Office 365

Office 365

If you’re diving into the wonderful world of developing for Office 365, or SharePoint Online, don’t let go of your development environment just yet!

Keeping your on premise instance of SharePoint 2013 for development will make a few things much easier, and will alleviate headaches in the long run.

For starters, make sure to have your environment configured with host named site collection, not separate web apps. This closely mimics how Office 365 is configured, and will help down the road. See this TechNet article for more details.

Errors

You heard it here first, Office 365 will error on you!

If you kept your on premises SharePoint, you can try the same app there, and if it errors, look through the logs. If it does not error, wait out Office 365 (more below).

I ran into this exact issue when developing a provider hosted app. Just couldn’t get past the error on Office 365. I spun up my virtual environment, tried it there, and received the same error. Searched the logs and found that my client ID wasn’t correct. Oops, I fat fingered something. Fixed and reran on Office 365 and success!

This won’t always work, as Office 365 does get updated more frequently than your environment does, and some of those updates may cause issues. Test it on your on-prem and then Open an Issue with Microsoft (more below).

You can also check the error log with your app, if you’re lucky. More on that here.

Waiting for Office 365

Sadly, Office 365 isn’t the best thing since sliced bread. Sometimes, Microsoft and team will randomly perform maintenance, and it appears whenever they want. I was working through the aforementioned provider hosted app, when all of a sudden, everything went read-only:

Site is read only Office 365

Great, now what?! Nothing. I couldn’t do anything, but my deadline kept getting closer!

What is a SharePointer to do? Dive into your on premise environment which you were wise enough to save, and finish development there. This read-only status kept for about 6 hours this day. This can really hurt development progress when this happens.

Another fun thing is when services get degraded.

Office 365 degraded SharePoint Online

This issue came up, and hindered one specific piece of what we were developing, sorry I forget what it is exactly. Sure enough, moving to on-premises saved the day.

One more story: I was working happily in Office 365 all day, with a deadline the next day, things were going smoothly. I left work at 5p, knowing I’d sneak in a little more work that night to polish up the app. I get home, enjoy my family time, and jump online once my kids are in bed. Sure enough, Office 365 is experiencing an issue and wouldn’t let me continue… grrr… Got up early the next morning and things started working again (I was able to meet my deadline).

Open an Issue with Microsoft

I have to hand it to Microsoft, their support team for Office 365 is responsive! Submit a support request through your tenant. If you’re working on someone else’s tenant, it’s okay, submit the request using your details. Gone are the days of having to submit under an account user just to hand the ticket off to someone else.

Once submitted, they call me back within 4 hours most times. Not too shabby. They aren’t the brightest set of support techs, sometimes things get escalated, but they really try hard to fix your issues.

Again, if you have your on-prem environment, you can submit the support request, then continue working on-prem.

Less Important, Until You Lose it

Office 365 is on the cloud, and if you lose your internet, you’re down. This may go for your on premises SharePoint as well if it’s not running locally on your workstation. Nothing hinders work more than not being able to access anything! Keep it mind.

Keep Your On Premises SharePoint

Just do it.

Advertisements

Troubleshooting SharePoint Quick Tip with the Logs

I just discovered a little trick for easing the process of reading and reviewing the SharePoint logs, so I thought I’d share.

Open a SharePoint log and you get an incredibly large file with so much info, especially if your logging is set to verbose. As I develop and I receive generic errors, I need to go into these aggravatingly large logs to find my real issue. Most cases it is easy enough to open it in Notepad++, search for the error and go from there.

I figured out this trick when troubleshooting a web part. I get a typical SharePoint generic error when trying to add it to a page. I find the error in the logs, and it’s just as generic there as well. Now I want to see the entire log history for adding the solution, activating the feature, and adding the web part to a page. I hope to find an error on solution install or feature activation.

So all I want to see is a small window of the log, not the entire thing. I could track my start time by staring at the server clock when I press Deploy and Activate, but even 10 seconds off can add dozens of lines in the logs.

What to do… let’s create a fresh new log for my activity.

Right before I’m about to perform my steps I want to monitor, I restart the SharePoint 2010 Tracing service. (go to Start > Administrative Tools > Services)

By restarting the service, this will create a new log file with the current date and time stamp. Now I walk through my process, recreate the error, and restart the service again. A new log file is created, and the previous one has that small window of time in it! Now I take this and I can comfortably read it, knowing I’m not reading more than I need. Sure enough, I found an assembly reference error on solution deployment.

Happy SharePointing!

Troubleshooting a SharePoint 2010 Service Pack 1 install

I was handed a SharePoint 2010 farm with some weird issues going on, specifically around PowerPivot.

First thing I checked was the status of any updates. Sure enough, there was an upgrade available (as seen in Central Admin > Manage Servers in this Farm). My continual troubleshooting of PowerPivot is in this other post.

I jumped to the SharePoint Management Shell and ran

psconfig -cmd upgrade -inplace b2b -force

And much to my surprise (NOT) I ran into the following error

An exception of type Microsoft.SharePoint.Administration.SPUpdatedConcurrencyExc eption was thrown.  Additional exception information: An update conflict has occ urred, and you must re-try this action. The object SPUpgradeSession Name=Upgrade -20120329-125109-783 was updated by domain\sp_admin, in the PSCONFIG (8484) process, on machine SHAREPOINT.  View the tracing log for more information abou t the conflict.

and from the upgrade log

03/29/2012 12:52:08  12  ERR            Task upgrade has failed with an unknown exception 03/29/2012 12:52:08  12  ERR            Exception: Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SPUpgradeSession Name=Upgrade-20120329-125109-783 was updated by domain\sp_admin, in the PSCONFIG (8484) process, on machine SHAREPOINT.  View the tracing log for more information about the conflict.    at Microsoft.SharePoint.Administration.SPConfigurationDatabase.StoreObject(SPPersistedObject obj, Boolean storeClassIfNecessary, Boolean ensure)    at Microsoft.SharePoint.Administration.SPConfigurationDatabase.Microsoft.SharePoint.Administration.ISPPersistedStoreProvider.PutObject(SPPersistedObject persistedObject, Boolean ensure)    at Microsoft.SharePoint.Administration.SPPersistedObject.BaseUpdate()    at Microsoft.SharePoint.Upgrade.SPUpgradeSession.Update()    at Microsoft.SharePoint.Upgrade.SPUpgradeSession.ContinueOnLocalThread(Guid id, Boolean consoleOutput)    at Microsoft.SharePoint.Upgrade.SPManager.ContinueSessionOnLocalThread(Guid id, Boolean consoleOutput)    at Microsoft.SharePoint.PostSetupConfiguration.UpgradeTask.Run()    at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

After some research online, I came across KB939308, which instructs to clear the timer job cache. I did that, and received the same error. I cleared the timer cache again and then it progressed past this error. I’ve had this “clearing of the timer cache twice” occur elsewhere as well, for some reason my initial attempt at clearing the timer cache never works well for me.

Rerunning the psconfig command progressed a little further than last time, but then a new error occurred.

An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfig urationTaskException was thrown.  Additional exception information: The upgrade command is invalid or a failure has been encountered. Failed to upgrade SharePoint Products.

and from the upgrade logs

03/29/2012 13:28:54  12  ERR            An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown.  Additional exception information: The upgrade command is invalid or a failure has been encountered. Failed to upgrade SharePoint Products. Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException: Exception of type ‘Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException’ was thrown.    at Microsoft.SharePoint.PostSetupConfiguration.UpgradeTask.Run()    at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

I found a lot of posts online, this issue is due to service applications’ associated services being stopped. I reviewed this and saw that most of the services were stopped on the server. I confirmed what was needed and removed the service applications for what was not needed, and started the services for what was needed.

Ran psconfig again, went a little further but ended up getting the same errors again. I then checked out the Upgrade-DATE-error.log file (didn’t see that one before) and that revealed a lot.

[OWSTIMER] [UpgradeWebConfig (4.0.2.0)] [INFO] [3/29/2012 2:31:41 PM]: Microsoft.SharePoint.Administration.SPIisWebSite [OWSTIMER] [UpgradeWebConfig (4.0.2.0)] [ERROR] [3/29/2012 2:31:41 PM]: Application Web Config for this IIS site (52113925) could not be found at C:\inetpub\wwwroot\wss\VirtualDirectories\site.domain.local80\web.config. [OWSTIMER] [UpgradeWebConfig (4.0.2.0)] [INFO] [3/29/2012 2:31:41 PM]: Microsoft.SharePoint.Administration.SPIisWebSite [OWSTIMER] [UpgradeWebConfig (4.0.2.0)] [ERROR] [3/29/2012 2:31:41 PM]: Unexpected error updating SafeControl entries. Object reference not set to an instance of an object. [OWSTIMER] [UpgradeWebConfig (4.0.2.0)] [INFO] [3/29/2012 2:31:41 PM]: Microsoft.SharePoint.Administration.SPIisWebSite [OWSTIMER] [UpgradeWebConfig (4.0.2.0)] [ERROR] [3/29/2012 2:31:41 PM]: Application Web Config for this IIS site (52113925) could not be found at C:\inetpub\wwwroot\wss\VirtualDirectories\site.domain.local80\web.config. [OWSTIMER] [SPIisWebSiteWssSequence] [INFO] [3/29/2012 2:31:42 PM]: Microsoft.SharePoint.Administration.SPIisWebSite [OWSTIMER] [SPIisWebSiteWssSequence] [ERROR] [3/29/2012 2:31:42 PM]: Action 4.0.2.0 of Microsoft.SharePoint.Upgrade.SPIisWebSiteWssSequence failed. [OWSTIMER] [SPIisWebSiteWssSequence] [INFO] [3/29/2012 2:31:42 PM]: Microsoft.SharePoint.Administration.SPIisWebSite [OWSTIMER] [SPIisWebSiteWssSequence] [ERROR] [3/29/2012 2:31:42 PM]: Exception: Object reference not set to an instance of an object. [OWSTIMER] [SPIisWebSiteWssSequence] [INFO] [3/29/2012 2:31:42 PM]: Microsoft.SharePoint.Administration.SPIisWebSite [OWSTIMER] [SPIisWebSiteWssSequence] [ERROR] [3/29/2012 2:31:42 PM]: at Microsoft.SharePoint.Upgrade.UpgradeWebConfig.EnsureAssemblyRedirection(XmlDocument webConfig) at Microsoft.SharePoint.Upgrade.UpgradeWebConfig.Upgrade() at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade() [OWSTIMER] [SPUpgradeSession] [INFO] [3/29/2012 2:31:42 PM]: Microsoft.SharePoint.Administration.SPIisWebSite [OWSTIMER] [SPUpgradeSession] [ERROR] [3/29/2012 2:31:42 PM]: Upgrade [Microsoft.SharePoint.Administration.SPIisWebSite] failed. [OWSTIMER] [SPUpgradeSession] [INFO] [3/29/2012 2:31:42 PM]: Microsoft.SharePoint.Administration.SPIisWebSite [OWSTIMER] [SPUpgradeSession] [ERROR] [3/29/2012 2:31:42 PM]: Inner Exception: Object reference not set to an instance of an object. [OWSTIMER] [SPUpgradeSession] [INFO] [3/29/2012 2:31:42 PM]: Microsoft.SharePoint.Administration.SPIisWebSite [OWSTIMER] [SPUpgradeSession] [ERROR] [3/29/2012 2:31:42 PM]: at Microsoft.SharePoint.Upgrade.UpgradeWebConfig.EnsureAssemblyRedirection(XmlDocument webConfig) at Microsoft.SharePoint.Upgrade.UpgradeWebConfig.Upgrade() at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade() [OWSTIMER] [SPUpgradeSession] [INFO] [3/29/2012 2:31:42 PM]: Microsoft.SharePoint.Administration.SPIisWebSite [OWSTIMER] [SPUpgradeSession] [ERROR] [3/29/2012 2:31:42 PM]: Exception: Action 4.0.2.0 of Microsoft.SharePoint.Upgrade.SPIisWebSiteWssSequence failed. [OWSTIMER] [SPUpgradeSession] [INFO] [3/29/2012 2:31:42 PM]: Microsoft.SharePoint.Administration.SPIisWebSite [OWSTIMER] [SPUpgradeSession] [ERROR] [3/29/2012 2:31:42 PM]: at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade() at Microsoft.SharePoint.Upgrade.SPUpgradeSession.Upgrade(Object o, Boolean bRecurse) [OWSTIMER] [SPUpgradeSession] [INFO] [3/29/2012 2:31:42 PM]: No context object [OWSTIMER] [SPUpgradeSession] [ERROR] [3/29/2012 2:31:42 PM]: Upgrade Timer job is exiting due to exception: Microsoft.SharePoint.Upgrade.SPUpgradeException: Action 4.0.2.0 of Microsoft.SharePoint.Upgrade.SPIisWebSiteWssSequence failed. —> System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.SharePoint.Upgrade.UpgradeWebConfig.EnsureAssemblyRedirection(XmlDocument webConfig) at Microsoft.SharePoint.Upgrade.UpgradeWebConfig.Upgrade() at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade() — End of inner exception stack trace — at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade() at Microsoft.SharePoint.Upgrade.SPUpgradeSession.Upgrade(Object o, Boolean bRecurse) at Microsoft.SharePoint.Upgrade.SPUpgradeSession.ReflexiveUpgrade(Object o, Boolean bRecurse) at Microsoft.SharePoint.Upgrade.SPUpgradeSession.Upgrade(Object o, Boolean bRecurse) at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively) at Microsoft.SharePoint.Upgrade.SPUpgradeSession.ReflexiveUpgrade(Object o, Boolean bRecurse) at Microsoft.SharePoint.Upgrade.SPUpgradeSession.Upgrade(Object o, Boolean bRecurse) at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively) at Microsoft.SharePoint.Upgrade.SPUpgradeSession.ReflexiveUpgrade(Object o, Boolean bRecurse) at Microsoft.SharePoint.Upgrade.SPUpgradeSession.Upgrade(Object o, Boolean bRecurse) at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively) at Microsoft.SharePoint.Upgrade.SPUpgradeSession.ReflexiveUpgrade(Object o, Boolean bRecurse) at Microsoft.SharePoint.Upgrade.SPUpgradeSession.Upgrade(Object o, Boolean bRecurse) at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively) at Microsoft.SharePoint.Upgrade.SPUpgradeSession.ReflexiveUpgrade(Object o, Boolean bRecurse) at Microsoft.SharePoint.Upgrade.SPUpgradeSession.Upgrade(Object o, Boolean bRecurse) at Microsoft.SharePoint.Administration.SPUpgradeJobDefinition.Execute(Guid targetInstanceId)

As you’ll see it mentions the web.config file for the web application, and that it cannot be found. I went and looked myself and discovered that was true, the web.config file was no longer present. After further review, it appears that most of the web applications on this server were stopped in IIS, and have been moved to another farm. This farm remained as a PowerPivot play ground only.

I spoke with the customer to confirm the sites were moved, and I also ran this quick script that loops through the web applications and pings each one, confirming the IP address was not this farm’s IP.

$webapps = Get-SPWebApplication
foreach($web in $webapps)
{
ping $web.url.replace(“http:”,””).replace(“https”,””).replace(“/”,””) -n 1
}

One web app came back as still on this server, and it was the web app used to run PowerPivot. I went ahead and deleted all of the other web applications and reran psconfig.

SUCCESS!

The upgrade finally finished and the server status was back to No Action Required. Now on to troubleshooting PowerPivot.

Improving SharePoint’s Performance

As SharePoint grows and morphs and becomes your information beast, it sometimes feels like it slows down. This is usually typical in implementations where the proper optimizations were not applied early on. It’s okay, it’s still possible to recover and improve some of your SharePoint’s loss of performance.

Disclaimer

Performance can be significantly degraded by using less than recommended specifications as Microsoft published. 4GB of RAM for a SQL server will slow it down no matter what we do. Make sure your hardware meets, or better yet, exceeds Microsoft’s recommendations! See Microsoft’s recommendations here: http://technet.microsoft.com/en-us/library/cc262485.aspx.

Is your farm big enough?

First thing to consider is the size of your farm. The rest of this post includes other pointers to improve performance, and should be considered regardless of the size of your farm. Your farm should never be a single server farm, unless you’re using it for development or testing. Even the testing environment should closer mirror your production environment. At minimal, your farm should consist of two servers, one for SharePoint and one for SQL. This is a minimal configuration and can survive with a dozen or two users at once. If you’re working with highly used sites, you should be considering at least a three+ server farm, and possibly some load balancing. Sizing a farm should be taken seriously, check out http://technet.microsoft.com/en-us/library/cc263199.aspx for some great references.

A quick note about disk drives.

I mention RAID and drive partitions and such. RAID stands for redundant array of independent disks. This technology allows your server to combine several drives into one large drive, and in turn, it can lose one drive (except for a RAID0) and keep all your data and server running. It magically copies data across multiple drives so if one is lost, there’s no loss of data. There are different configurations available and pros and cons for each: RAID0, RAID1, RAID5, RAID10 are the more popular configurations. Whatever your configuration, the operating system will see your multiple drives as one large drive. For example RAID1 mirrors data, across two identical drives, so if you have two 250GB drives in a RAID1, Windows will only see 250GB. RAID5 requires at least 3 drives and writes the data across all three, so if you have three 250GB drives, Windows will only see 500GB. RAID5 tends to be faster in writing as it can write more data on 2 different drives at once, verse a RAID1 where the same data is being written twice. I hope that clears some stuff up.

If you haven’t formatted your disks yet, or installed anything of consequence, consider a reformat.

[When formatting your disk] On the “File System Settings” page, select NTFS for the File system, select 64K for the Allocation unit size and type “SharePoint Databases” for the Volume label.  Click the Next button. Changing the allocation unit (i.e. cluster) size from the default 4K to 64K is absolutely necessary at this juncture. This setting cannot be changed later without reformatting the disk! Why is 64K considered a best practice? Because SQL Server reads and writes data 64 KB at a time. Increasing the cluster size reduces fragmentation and the number of times disk space needs to be allocated, which can improve reading and writing speed. Since these disks will be used solely for storing SQL Server files, I’m not concerned about the slack (i.e. wasted) space that can occur when the cluster size is too large.

From  http://chrisbarbin.wordpress.com/2014/01/19/sql-server-2012-vm-notes-part-3/. Thanks to Chris for the tip!

The database

The database is a common area where performance hits are most prevalent. SharePoint is database intensive, about 95% of SharePoint is stored in a SQL database: files, images, videos, pages, content, user profiles, etc. It’s important to have a happy and health SQL database running.

Things to do or check

  • Make sure databases are running on RAID5 or RAID10 partitions. These two RAID configurations provide the fasted throughput for constant read/write activities. If you’re on a RAID1, consider moving your databases.
  • Check your drive’s free space. Make sure you have several gig available. If it gets too small SQL still start acting funny, and slower. If it get to a gig or under it’ll stop working all together.
  • Check your content database size and growth properties in SQL Server Management Studio. If these are set too low, then SQL has to resize itself a lot and that can slow it down.

To check your database properties

  • Connect to the database server using Microsoft SQL Server Management Studio.
  • Right click your database and select Properties.
  • Go to Files on the left.
  • You should now see 2 rows for your database.
  • Select the one with a File Type of Rows Data.
    • This represents your database file, where all the stuff is stored.
    • Note the initial size. If this site is new and young and doesn’t have much on it, set that initial size to an estimated file size for the future. If it’s an existing content database with a load of data, don’t worry about the initial size. By setting this above and beyond, it’ll resize the database now, instead of later.
    • Note the Autogrowth setting. Modify this to be 25%-50%, higher if the site will be loaded up with a lot of data coming soon. Again, this will resize the database once and cover a lot of data. The default property values requires SQL to resize frequently, and therefore imped performance of the server while it’s resizing.
  • Now select the File Type Log.
    • This represents your transaction logs. As items are being written to and from the database file, the transaction log keeps a log of it, in the event of a database failure, you can technically restore back to the last transaction. This log can grow exceptionally large depending on traffic on your sites.
    • Following the same rules as above, the initial size should be around 25% of the data file initial size.
    • Set autogrowth to 25%-50%, again depending on amount data that will be loaded.
  • If possible, these two files should be on different physical disks, not just different logical disk partitions.
    • This might be difficult as most servers have a single RAID container. In larger implementations, if you have additional drives available, separate the data and log files. Moving them onto their own physical disks or disk arrays, the drives can spin independent of each other, therefore improving performance.
  • Next, go to Options on the left
  • The Collation option should be Latin1_General_CI_AS_KS_WS (SharePoint’s preferred setting).
    • This setting handles how the database treats some finer settings like case sensitivity. If the database was created by SharePoint, you’re fine. If a DBA or someone else made the database first, this might not be set correctly.
  • Click OK.
  • Expand System Databases on the left, and do the same as the above to the tempdb.
    • The tempdb is a temporary location data is handled while it waits for other processes to finish. The tempdb prefers RAID10 over all.

Another consideration for improving database performance is RBS, I go into greater detail on RBS in this post.

SharePoint Logs

SharePoints logs are usually on the drive it was installed on, and in most cases that’s the C drive of the server. It’s recommended to moved these logs to another partition, and preferably different drives altogether.

  • Go to Central Administration > Monitoring > Configure Diagnostic Logging.
    • Note the top part, Event Throttling. This specifies what SharePoint will log. If any of these have been changed from default, they’ll be in bold. Your ideal settings for all of them are
    • Least critical event to report to the event log: Information
    • Least critical event to report to the trace log: Medium
    • In the next section, Event Log Flood Protection, make sure that’s checked.
    • And in Trace Log section, feel free to move the logs to a different drive to either free up space on the current drive or to a unique drive. You may limit the amount of days or space the logs use per your preference.
    • Click OK.

Large lists are slow

If you have lists that have several thousand records in them, those lists may run slow as you load views. Other lists which use your large lists in a lookup field may also slow down as it has to process all of the records.

You can enable indexing on your SharePoint fields within your lists to improve lookup speeds and page loads. Go to your list settings, then under the column list is a link Indexed Columns. Select your columns that you will be searching against, creating filtered views with or using in lookups.

Keeping it alive

This issue is less of an issue as it’s just how technology works. If SharePoint (rather the services running SharePoint: IIS) runs idle for a set amount of time, usually 20 minutes, the services will go to sleep and cache is cleared. As a result, when a user goes to access SharePoint, the services have to start up, and build the cache again. This can set an initial load to take several seconds, which to an end user can be forever. There’s a neat little application available at http://spwakeup.codeplex.com/ which tickles your sites to keep them awake.

Funky Code

How many custom features are you using? Does it seem to slow down when they’re in use? This might be hard to determine as a highly used site might be hitting custom code left and right. If you’re a developer, or want to tell your developer something, check these out

  • Make sure all SPSite and SPWeb objects are disposed of cleanly. There is a free tool which will check your compiled solution for you, download SPDisposeCheck here http://archive.msdn.microsoft.com/SPDisposeCheck.
  • If you’re adding new items to a list that has thousands of records, don’t simply perform SPList.Items.Add(). This will actually load all your items into memory, then create a new record. Instead, do something like SPQuery qryEmpty = new SPQuery() { Query = “0” }; SPList list = web.lists[“Name”]; SPListItem newItem = list.GetItems(qryEmpty).Add(); This will load an empty results set first, then give you a new item. Also, check out the note above on Large lists are slow.
  • Check the status of workflows, ensure they aren’t looping. This is a common issue with developing custom workflows. If the workflow updates the item the workflow is running on, it’ll loop because it was updated again. And around and around you go. Make sure to include some validators in your workflow to ensure you want to perform the update, not just update it.
  • Check out http://bestofcyber.wordpress.com/2008/10/16/best-coding-techniques-to-improve-performance-for-sharepoint-applications/ for some more information on improving your code.

Am I missing some? Please, leave a comment and let me know!!

Effectively reading SharePoint Logs

I don’t think anyone actually enjoys reading the SharePoint logs. It can be overwhelming. I’ve found a few techniques to mastering the logs and finding what you really want, fast.

First, you need to crank up diagnostic logging in Central Admin. The default logging levels don’t do a good job of reporting everything. So hop in there and crank it down to log everything. MAKE SURE TO REMEMBER TO SET IT BACK! Especially on a production farm, these logs can get big, fast.

There’s a great free application called SharePoint LogViewer. It starts up slow, but once it’s running, it’s great. It monitors all logs on all servers within your farm, providing an almost (2-3 seconds behind) real-time look into what’s going on. SharePoint LogViewer is a very powerful tool for troubleshooting issues on your server and farm.

By default, it only keeps 500 lines on the screen, which depending on your farm might only be a minute or two of entries. Click the settings gear icon and you can ramp that up, I throw it up to 5000, giving me closer to 5-7 minutes of entries. Again, this will depend on the amount of traffic your farm is experiencing.

If the constant streaming is tough to manage or if you’re ready to stop the log to read through some of the entries, click the little pause button and you can now look through the entries and perform some searching and filtering. As you analyze your logs, and narrow down to a subset of records you can save the log entries, giving you a small log with just the records you want.

SharePoint LogViewer takes up a minimal amount of resources on the server. I ran it on a 6 server SharePoint 2010 farm on one of the application servers, and it averaged 10% of the processor and the memory used reached 60MB. This resource usage is very reasonable for our farms.

As great as that app is, I find myself jumping to another app for a quick read. I’ll use the above when I need to really analyze and troubleshoot when something isn’t obvious. The other tool I love is Notepad++. It works a lot like NotePad, but has some added features. With NotePad++, you can open multiple log files and search against all of them at once. This is helpful if you need to open the last week of logs to find an issue a user complained about. It also provides keyword highlighting, which is helpful when searching for a page or correlation ID. Double click or search for a word and all instances of the word will highlight right in the page making it easy to find your references.