SharePoint components - business processes without development, InfoPath, SharePoint Designer or workflows. SharePoint Services, SharePoint Foundation & SharePoint Server 2010-2016.

Category: Administration
Current page:

Service Jobs in SharePoint 2016

By: Genady Vaisman | Comments [0] | Category: Administration | 7/10/2017

The latest SharePoint version introduces a new setting that can be applied to each of the timer server instances: AllowServiceJobs

When this attribute is set to false, basically this server will not be able to execute timer jobs with SPJobLockType: Job ("Service Jobs").

This type of lock is needed to ensure that this timer job is executed only on one of servers, basically to prevent multiple executions of the same logic.

Several of our products are affected by this setting: Smart Import ProSmart Action ProNewsletter. These Products will not be able to function properly in regards of their background / timed functionality. Another impact may be on the installation process, in terms of failure in deploying required recourse files.

Mind that this behavior can be caused only on SharePoint 2016 farms, as previous versions did not allow this setting to be controlled.


You can use the following PowerShell script to determine the value of this property in your farm:

$farm = Get-SPFarm

$FarmTimers = $farm.TimerService.Instances

foreach ($ft in $FarmTimers)


       write-host “Server: ” $ft.Server.Name.ToString();

       write-host “Status: ” $ft.status;

       write-host “Allow Service Jobs: ” $ft.AllowServiceJobs;



And the following script to enable it:

$farm = Get-SPFarm

$FarmTimers = $farm.TimerService.Instances

foreach ($ft in $FarmTimers)


      if ($ft.AllowServiceJobs -eq $false)


             write-host “Service jobs are NOT enabled on ” $ft.Server.Name.ToString();

             write-host “Enabling service jobs”;

             $ft.AllowServiceJobs = $true;





             write-host “Service jobs are enabled on ” $ft.Server.Name.ToString()






Connecting to Exchange Online from Ultimate Forms for Office 365

By: Vladi Gubler | Comments [0] | Category: Administration | 3/29/2016


Several of Ultimate Forms components can interact with your Exchange Online:

  • Alerts will send your alerts through Exchange Online mailboxes
  • Import will import emails from Exchange Online mailboxes
  • Print will send your print-outs to recipients through Exchange Online mailboxes
  • Actions will automate printing and send the print-out through Exchange Online mailboxes
  • Calendars will display your Exchange Online calendars in an app part, as well as allowing you to add new events directly from the app part

To be able to establish a secure connection to Exchange Online and send or receive items from Exchange Online, we have to receive a valid access token. Print is the simplest component, as it always runs interactively. When an access token is needed, you will be prompted for your consent (just once) and that's it. Pop-ups must be allowed so you will see the consent window.

For other components, it's a bit more complicated. As they mostly run in the background, there is no way to ask the user for the consent at runtime. We need to request an administrative consent beforehand instead. Because this consent applies to all the users of the tenant, a Global Administrator's consent is required. Depending on the component, it's given in different ways:

  • Alerts: an administrator has to visit the Administration page (accessible from the gear icon in the top right corner of the Alerts page). There, click on the Grant button (at the button of Adminstration section). That's it, the app can now send alerts on your behalf. You can always retract your consent through your Azure administration settings.
  • Import: when you first create an import profilee that uses Exchange Online, you will be prompted for consent. It is given just once, all subsequent profiles can be added without it.
  • Actions: when you try to save a Print (or Active Directory) action, you will asked for consent, even if one has already been given in the past
  • Calendars: when you add an Exchange data source, you will be asked for consent if it's the first ever Exchange data source.

That's it, not too complicated. Just make sure you have the necessary permissions, otherwise you will receive a Sign In error in the consent page and the error message will ask you to log in as an administrator.


How Ultimate Forms for Office 365 is updated

By: Vladi Gubler | Comments [1] | Category: Administration | 3/17/2016


Those of you coming from the on-premises environment are used to frequent version upgrades and try to keep your product up to date to take advantage of latest features and bug fixes. But how do you keep the app version up to date?

Well, the short answer is you don't need to. Because the app is hosted by us, it is always up to date. We constantly add new features and fix issue, to make sure you get the absolute maximum. Pay close attention and from time to time you will discover changes in the settings, new options, a more simplified approach and so on. Most server-side components require no action on your part.

The only components that do require some sort of intervention are the client-side form-oriented components (tabs, special columns and so on). The way these work is by uploading the latest scripts from our website into yours each time you save your settings. So when we release a new version of the script, it is not immediately available to your site, but must be uploaded by re-saving the settings. In some cases, the script is also cached by your browser and that cache might need to be manually cleared.

It doesn't mean that you actually need do anything proactively. The new script will be implemented when you take advantage of the new features and the old script is still functional and will work great.

So in conclusion: Office 365 approach gives you peace of mind, that's one of the greatest promises of the cloud!


Microsoft DPM - The best backup/restore solution for SharePoint 2010

By: Ethan Bach | Comments [2] | Category: Administration | 7/21/2010

We’ve all been in this situation – after a good long SharePoint based portal implementation – we start scratching our head to figure out what's the best way to back up the SharePoint farm and drown in the multitude of options – SharePoint native backup, stsadm or 3rd party products like AvePoint or EMC.
Now, Microsoft makes our life very easy by announcing Data Protection Manager as the main backup/restore application for SharePoint 2010.
Well, you might think that’s just another one of the many methods to protect SharePoint 2010 but DPM hides under its hood some pretty cool features which make it the #1 backup/restore application for SharePoint 2010. Here are some of them:

  • Application Awareness – it is probably one of the most important features of DPM, DPM is aware that it's backing up SharePoint and not any other solution when backing up SharePoint databases. The meaning of this is that DPM works hand in hand with SharePoint and as the result of that the backed up data is more consistent as DPM makes sure that all the transactions that are occurring during the backup are taken into consideration.
  • Item Level Recovery – DPM enables to recover a single object out of a full farm backup of a wide variety of SharePoint objects, such as documents, lists, document libraries, sites and sites collections.
  • Protects SharePoint Search. In a large farm the search index can get rather big. In these situations - backing up search is crucial as in a case of disaster it could take very long time, even days, to index the farm again.
  • Better Performance – DPM runs a very light agent which almost does not affect the farm production environment, with very low I/O, as it scans memory blocks to track changes in real -time.
  • Self-Healing Backup Process – during the backup, if one of the backup objects, such as server or database, goes offline – DPM will proceed with the backup as planned and try to self-heal and add the offline object during the next planned backup.
  • Reduce Storage Costs – DPM aims to use disks as the main backup storage and tapes for archiving. It's very understandable as disks are cheaper and more common than tapes and it's very easy and quick to restore data from them.
    Furthermore, DPM reduces storage costs by minimizing backed up data by backing up only the changed blocks of data, meaning that every backup after the first full backup is approximately 5% (average daily data change on a SharePoint farm) of the whole farm data. That saves about 75% of storage space comparing to differential SharePoint native backup over a one month period.
  • Search for Content (across Recovery Points). DPM enables to search the backed up data. It's very helpful if we want to perform an item level recovery, DPM search makes it very easy to locate an item to recover when needed and the time factor is crucial.


DPM is a great SharePoint 2010 backup/restore solution. And the fact it comes from Microsoft is a big advantage over other solutions as it integrates well with SharePoint within the backup/restore processes.
It very important to mention that DPM actually is the main Microsoft backup/restore solution for other Microsoft products such as Active Directory, Exchange, SQL, Virtual Server, file shares, System State and more. So it’s a great new backup/restore product family from Microsoft.

For more information –
Try it! There's also a 180 days evaluation download.


What’s New in SharePoint 2010 Capacity Planning

By: mor | Comments [2] | Category: Administration | 7/19/2010

Originally posted on ""

Whether you are upgrading or deploying a new SharePoint 2010 farm, the capacity boundaries are one of the the most important thing you need to understand to have a successful deployment.
When designing a farm, people need to be educated about how best to scale. These links below contain a lot of word docs, essentially you may find it more difficult to find the guidance you’re looking for, but there is actually already way more information published at release than in the earlier version.
New TechNet documentation and Whitepapers have just became available:
  • Capacity management and sizing for SharePoint Server 2010 – Kelley Vice (Thanks for gathering this, there’s guidance here that is applicable even to 2007)
  • SharePoint Server 2010 performance and capacity technical case studies (Includes one example of Collab and one of Publishing)
  • SharePoint Server 2010 performance and capacity test results and recommendations (Various documents including: Access Services, Large Lists max performance, Divisional Portal, Infopath, Performance Point, Search, Web Application Services, Web Content Management, Workflow)

    • Designing Large Lists and Maximizing Performance
    • Estimate performance and capacity requirements for Access Services
    • Provides guidance on how using Access Services impacts topologies running SharePoint Server 2010.
    • Capacity Planning and Sizing for SharePoint Server 2010-based Divisional Portal
    • Provides guidance on performance and capacity planning for a SharePoint 2010 based divisional portal.
    • Designing Large Lists and Maximizing List Performance
    • Provides guidance on performance of large document libraries and lists. This document is specific to SharePoint Server 2010, although the throttles and limits that are discussed also apply to Microsoft SharePoint Foundation 2010.
    • SharePoint Server 2010 Capacity Management for InfoPath Solutions
    • Provides guidance on the footprint that usage of InfoPath Forms Services has on topologies running SharePoint Server 2010.
    • Estimate performance and capacity requirements for PerformancePoint Services
    • Provides guidance on the footprint that usage of PerformancePoint Services has on topologies running SharePoint Server 2010.
    • Estimate performance and capacity requirements for Search in SharePoint Server 2010
    • Provides capacity planning information for different deployments of Search in SharePoint Server 2010, including small, medium, and large farms.
    • SharePoint Server 2010 Capacity Management for Web Content Management Deployments
    • Provides guidance on performance and capacity planning for a Web Content Management solution.
    • Word Automation Services 2010 Capacity Planning Guidance
    • Provides capacity planning guidance for Word Automation Services in SharePoint Server 2010.
    • Estimate Performance and Capacity Requirements for Workflow in SharePoint Server 2010
    • Provides guidance on the footprint that usage of Workflow has on topologies running SharePoint Server 2010.
  • Databases That Support SharePoint 2010 Products
  • Topologies for SharePoint Server 2010
Note: I highly recommend digging into these docs to better understand what these various “limits” are. There is much more information on new types of limits. Essentially there are now boundaries, thresholds, and supported limits. Much of these limits come down to testing. “The capacity planning information in this document provides guidelines for you to use in your planning. It is based on testing performed at Microsoft, on live properties. However, your results are likely to vary based on the equipment you use and the features and functionality you implement for your sites.” My personal recommendation is to be cautious. There are very few of these limits I’d recommend passing or even getting close to passing.
I was interested in providing a comparison of how things have changed based on the SharePoint 2007 capacity boundaries and 2010 capacity boundaries document. Here are some of my observations in differences that are worth noting. There is more the same than different when it comes to capacity planning. Don’t throw out all of your knowledge of SharePoint with what you find that’s new. A lot of the best practices are the same. Here’s my list of SharePoint 2007 key capacity planning blogs and articles.
The biggest key changes…
SharePoint 2007
(recommended max)
SharePoint 2010
(recommended max)
Items per view 2000 5000
Documents per library 5 million 10 million
Database size 100GB 200GB (up to 1TB for workloads)
Simultaneous Doc Editors 1 (no Multi user editing of Word, Excel, PPT) 10 (max at 99)
Column 2000 per doc lib, 4096 per list with (rowOrdinal) New Row Wrapping (8,000 bytes)
Content Databases per Web App 100 300
App Pools per web server 8 10
Indexed (Crawl Count) 50 Million items per SSP 100 Million per search Application
Site Collections per Web App 50,000 500,000
Items per view
If there was one thing that was a focus it was list scale. Not only is the list itself much more scalable, and better designed, but also the actual rendering of the lists is more flexible and more manageable. I’ve discussed the list threshold throttling limits where you can control how much is returned in a view. In 2007 we had a recommended limit of 2000. This 2000 number found itself as a key designing principal. Now the default is 5000 and this is as well the recommended max for a view more than doubling the previous limit. I’ve seen examples where this was increased and still the list rendering had much better performance than in 2007. … “Maximum number of list or library items that a database operation, such as a query, can process at one time, outside of the daily time window set by the administrator during which queries are unrestricted.”
Documents per list

Column Limits
What seems like a decent investment is row wrapping. SharePoint Server 2010 data is stored in SQL Server tables. To allow for the maximum number of possible columns in a SharePoint list, SharePoint Server will create several rows in the database when data will not fit on a single row. This is called row wrapping. Six rows are recommended as a maximum.
Site Collection Sizing
25 to 100GB “A site collection should not exceed 100 GB unless it is the only site collection in the database. Certain site collection actions, such as site collection backup/restore or Move-SPSite, cause large Microsoft SQL Server® operations which can have performance impact or fail if other Site collections are active in the same database.”
Published recommendations go from 2007 as 100GB content databases and in SharePoint 2010 looking at 200GB with possibilities of up to 1TB with careful non collaborative workloads like documents and records repositories. “We strongly recommended limiting the size of content databases to 200 GB to help ensure system performance. Content database sizes up to 1 terabyte are supported only for large, single-site repositories and archives with non-collaborative I/O and usage patterns, such as Records Centers.”
While structurally the blobs are better managed and more scalable, the fundamental storage story has changed a bit. We had EBS support with SharePoint 2007 SP1, but implementing anything was complex and many cautions against doing anything unless you had support with a vendor and even then, proceed with extreme caution. With SharePoint 2010 and SQL 2008 R2 we have a better story with RBS (Remote Blob Storage) essentially handled transparently by SQL. SharePoint 2010 is happy to have SQL store its blobs on external storage using a provider mechanism.
Databases per Web App & App Pools per Server
Knowing people are using 64 bit hardware you’ll see a few recommendations simply based on better scale with SQL and IIS. Examples of this is the numbers of databases per web app and the number of app pools per server which totally depends on the RAM on the box. SharePoint 2010 by default does not use less memory than SharePoint 2007. For example with App Pools, “This limit is dependent largely upon: 1) The amount of RAM allocated to the front end server 2) The workload that the farm is serving – the user base and the usage characteristics (the process of a single highly active application pools can reach 10 GB or more)”
Index Sizing
“SharePoint Search supports index partitions, which each contain a subset of the entire search index. The recommended maximum is 10 million items for a given partition. The overall recommended maximum number of items: e.g., people, list items, documents, Web pages, etc., is 100 million.”